Bug 1308544 - [RFE] Allow automatic assignment of subscriptions to hypervisors discovered by "virt-who"
[RFE] Allow automatic assignment of subscriptions to hypervisors discovered b...
Status: NEW
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Subscription Management (Show other bugs)
6.1.6
All Linux
high Severity medium (vote)
: Unspecified
: --
Assigned To: Eric Helms
Katello QA List
: FutureFeature, PrioBumpGSS, PrioBumpPM
: 1307036 1353697 (view as bug list)
Depends On:
Blocks: 1296845 1353215
  Show dependency treegraph
 
Reported: 2016-02-15 08:35 EST by Christian Horn
Modified: 2017-08-03 03:38 EDT (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2159981 None None None 2016-02-15 08:37 EST

  None (edit)
Description Christian Horn 2016-02-15 08:35:59 EST
Description of problem:

virt-who is currently running against our vCenter and reporting some hundred ESXi machines. The hosts are discovered, but no subscriptions assigned.

Ww need to assign each of these hypervisors the "datacenter"-subscription which allows unlimited guests by hand: open up Satellite UI, navigate to Content Hosts, select one, go to the Subscription tab, add the desired subscription. That works fine, but will not scale for hundreds of machines.

Running an auto-attach bulk action does not lead to the expected result, as Katello thinks there is no product installed on the ESXi and thus no new sub is needed (technically correct, but nontheless it should get the unlimited-guests subscription.

"hammer content-host update" does not allow to attach a subscription to a host
"hammer subscription" does not allow that either
Thus we have no way to do it in an easy for-loop in shell

There is the API which we used for now, but is slow (takes around 13 minutes at the moment) and is uncomfortable and errorprone for own scripting.

Version-Release number of selected component (if applicable):
6.1.6

How reproducible:
always

Steps to Reproduce:
1. discover a number of hypervisors via virt-who

Actual results:
no method to have subscriptions assigned to these discovered hypervisors

Expected results:
there should be a way to assign subscriptions "in a bulk mode"

Additional info:
Comment 4 Bryan J Smith 2016-02-29 13:58:22 EST
Just to document the "workarounds" that usually (not absolute, but nearly always) work ...


Option 1 - Single Activation Key - register (w/host-key), remove, re-attach ...

  # subscription-manager register --org="Default_Organization" --activationkey="ak-x64elX_host"
  # subscription-manager remove --all
  # subscription-manager attach --auto


Option 2 - Dual Activation Keys - register (w/host-key), unregister, re-register (w/guest-key)

  # subscription-manager register --org="Default_Organization" --activationkey="ak-x64elX_host"
  # subscription-manager unregister
  # subscription-manager register --org="Default_Organization" --activationkey="ak-x64elX_guest_typeY"


The 1st command, using a "host key" that _forces_ a subscription to be Virtual Datacenter or other "unlimited guest," causes two (2) entitlements to be consumed ...
 1)  For the guest, which seemingly gets "entitled first"
 2)  For the ESX or other, non-RHEL HyperVisor host, which seemingly gets "entitled second"

It seems there is an issue with how Katello-Foreman and Candlepin interact, wherasa the "guest" is in the state diagram or other, logical flow, before the host -- which might be okay with Red Hat HyperVisors, but not others where Subscription-Manager/Satellite is not directly making API calls to the host environment (e.g., vCenter in the case of ESX).

The 2nd and 3rd commands depend on whether or not the guest re-attaches to the correct entitlement/subscription.

If so, the #1 option can be used -- remove then auto-attach, which only affects the guest.

If not, or the guest needs to have specific content views, repos, etc... enabled, then the #2 option is _required_.  Unregister, which only affects the guest, and then re-active using a "guest" specific type (for the systems use/subscriptions) activation key with the appropriate channels, content views, etc... required.
Comment 8 Evgeni Golov 2016-03-23 04:06:01 EDT
FTR, I wrote and am currently using https://github.com/evgeni/katello-attach-subscription as an workaround.
Comment 10 Bryan J. Smith 2016-03-24 17:30:47 EDT
Interesting workaround.

I'm hoping to have Satellite 6 on-line at my new client, who also uses VMware (like my prior client), soon to test.  Right now my new client is only using the upstream components (Katello, Foreman, Pulp, et al.), so no Candlepin.

The only thing I want to point out, if I'm reading the Ruby correctly, is that Red Hat will have customers with HyperVisors that have no RHEL guests.

I.e., It is not uncommon and, in fact, quite common for most of Red Hat customer's to be running a non-RHEV HyperVisor, like VMware, because their Windows division specified the requirements, and the Linux team has been moved on to it without any input.  So ...

E.g., RHEL guests are often only running on a subset of the total HyperVisors, especially if it's the minority OS on VMware at the customer.

Q1:  In those cases, how well does that workaround work for HyperVisors with no guests?  Or, more importantly yet ...

Q2:  The cases when a RHEL guest moves from the HyperVisor, and is no longer running on the HyperVisor, and possibly no RHEL guests on the HyperVisor?

These are "real world" questions customers are asking with virt-who, especially with Satellite 6 / Katello.  I will also include a non-technical, real-world entitlement scenario / viewpoint from the common customer.

<non-technical>
I'm not with Product Management or Entitlement Enforcement, but I've always felt our best move with Candlepin et al. is to reconcile HyperVisor entitlement night -- once per day -- and give our customers the power to self-report their "worst case" of HyperVisors in use on one night over, say, a quarter.

E.g., say a customer only has 16 HyperVisors in use, on average, but due to loads, there were 2 nights in the quarter when they had 20 HyperVisors utilized.  We should give them the tools to self-report that they need to license for 20.  I also think we should be flexible enough to allow up to 25% more usage, which then they self-report for their next check-up or renewal (usually quarterly with their SA and/or TAM) with their Red Hat representative, which only helps Red Hat's bottom line.

I understand this is unrelated to the ticket, but I'm including it regardless.  I've always been about empowering the customer to self-report, as they are Red Hat's best customers and only often argue to buy more Red Hat.
</non-technical>
Comment 11 Evgeni Golov 2016-03-29 05:14:03 EDT
Hi,

(In reply to Bryan J. Smith from comment #10)

> The only thing I want to point out, if I'm reading the Ruby correctly, is
> that Red Hat will have customers with HyperVisors that have no RHEL guests.

you can filter those Hypervisors both in virt-who (see filter_host_uuids, exclude_host_uuids in virt-who-config(5)) and in katello-attach-subscription (see https://github.com/evgeni/katello-attach-subscription: "Each subscription hash has an hostname entry which will be used as an regular expression to match the hostname of the content host in Katello"). or you could limit your vCenter user to only see Linux Hypervisors.

> Q1:  In those cases, how well does that workaround work for HyperVisors with
> no guests?  Or, more importantly yet ...

Works just fine with my customers :)

> Q2:  The cases when a RHEL guest moves from the HyperVisor, and is no longer
> running on the HyperVisor, and possibly no RHEL guests on the HyperVisor?

Well, you'd need one sub for every Hypervisor that can *potentially* run RHEL guests as a RHEL guest might be migrated to such a Hypervisor at some point in time.

> These are "real world" questions customers are asking with virt-who,
> especially with Satellite 6 / Katello.  I will also include a non-technical,
> real-world entitlement scenario / viewpoint from the common customer.

I am not aware of any good customer-facing docs on this, I guess a BZ is the best way to get it done.
Comment 14 Bryan J. Smith 2016-04-13 18:24:10 EDT
> Well, you'd need one sub for every Hypervisor that can
> *potentially* run RHEL guests as a RHEL guest might be
> migrated to such a Hypervisor at some point in time.

That's my concern.

Why can't we reconcile each day how many HyperVisors were actually used?
Not how many could be *potentially* used?

We should *always* approach this from a customer-side, self-reporting view.
Virtually all of Red Hat's customers like to self-report and pay money.

Or should I flip this to say ...

Red Hat now the virt-who solution and tracking in Satellite 6 utterly confuses them to the point they do *not* understand what they are using.

Most Red Hat customers just want to know what they are *actually* using.  Why?  Again, they self-report.  They want to be compliant.  They want Red Hat to continue.  They know if they cheat Red Hat, they are only cheating themselves and their future with the platform.

Hence why the tool should work from a customer reporting standpoint, one they can understand.
Comment 17 Bryan Kearney 2016-07-08 11:18:04 EDT
*** Bug 1353697 has been marked as a duplicate of this bug. ***
Comment 18 Andrea Perotti 2016-07-08 12:57:09 EDT
An addendum from a customer to this RFE is to think about some automation, to let satellite spot cluster with RHEL VMs in and then attach:

1. Proposed title of this feature request
Assign automatically subscription to all hypervisor of a cluster if RHEL guests are present in the cluster.

3. What is the nature and description of the request? 
This case is linked to #1307036
We need virt-who to guess if there are RHEL guest into vmware cluster.
If there is any ([1..N]) virt-who need to automatically attach subscription to all of the hosts present in the cluster.
Comment 19 Bryan Kearney 2016-07-11 08:24:02 EDT
Looking at a duplicate bug (https://bugzilla.redhat.com/show_bug.cgi?id=1353697) it seems like the expected behaviour is to have the following:

1) Be able to assign subscriptions to all newly discovered hypervisors.
2) Be able to assign subscriptions only to hypervisors with RHEL guests.
3) Have a job which runs on a scheduled basis which does the following:
a) Remove subscriptions from hypervisors with no guests
b) Adds subscriptions to hypervisors with guests
Comment 20 Daniele Palumbo 2016-07-11 13:49:40 EDT
(In reply to Bryan Kearney from comment #19)
> Looking at a duplicate bug
> (https://bugzilla.redhat.com/show_bug.cgi?id=1353697) it seems like the
> expected behaviour is to have the following:
> 
> 1) Be able to assign subscriptions to all newly discovered hypervisors.
> 2) Be able to assign subscriptions only to hypervisors with RHEL guests.
> 3) Have a job which runs on a scheduled basis which does the following:
> a) Remove subscriptions from hypervisors with no guests
> b) Adds subscriptions to hypervisors with guests

This is partially correct, looking at the bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1353697 .

1) Be able to assign multiple subscriptions to all newly discovered hypervisors. -> note multiple
2) Be able to assign subscriptions only to hypervisors that belong to a cluster with RHEL guests, based on regexp on cluster name. -> belong to cluster and regexp
3) Have a job which runs on a scheduled basis which does the following: -> belong to cluster
a) Remove subscriptions from hypervisors belonging to a cluster with no guests
b) Adds subscriptions to hypervisors belonging to a cluster with guests
c) (a+b) Change subscriptions to hypervisors that changed cluster and have different guests

use cases:

#1 
for multiple subs can be handled through https://bugzilla.redhat.com/show_bug.cgi?id=1344049 as well
use case: 
subscription that are unlimited guest but without smart management. smart management must be added to all of the hosts.

#2 
see also https://bugzilla.redhat.com/show_bug.cgi?id=1307036#c10
Generally, one hypervisor always belong to a cluster.
Sometime, some hypervisor can have 0 RHEL servers associated, but the expectation is that if a vmotion is made, the guest will continue to have a valid subscription.
Also the number of subscription, if the cluster is not taken in consideration, may vary from day to day.

About regexp, the hostname of the hypervisor may be a standard one.
What is usually meaningful is the cluster name.

#3 
one hypervisor with sub 123 is assigned to one cluster.
this sub is standard, and the cluster belong to QA environmnet.
the host move to another cluster (remind that has already one sub, and that hostname do not change).
the hypervisor should drop the sub 123 the standard one, and get the 456, the premium one.

HTH
Comment 22 Bryan Kearney 2017-06-15 12:27:34 EDT
*** Bug 1307036 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.