Bug 1126924

Created from redmine issue http://projects.theforeman.org/issues/6939

*** Bug 1123668 has been marked as a duplicate of this bug. ***

In case we are going to change behaviour here, would it be possible to add option to allow use any available pool for given organization? (Instead of explicitly enumerating all of them, as that leads to complications when new pools are available). This would not only move Sat6 activation keys closer to those of Sat5 but also make transitioning of activation keys possible/more pleasant.

*** Bug 1132374 has been marked as a duplicate of this bug. ***

Activation Keys will be a key part of any automation strategy, and this really makes things difficult.

For example, you might have an AK "Test RHEL 7 - Apache Web Servers" which is used by a similarly named host group -- this would make sure that things like SCL and another other important repos are enabled by default.

Subscriptions of the same kind, e.g. 'Red Hat Enterprise Linux w/ Smart Management' should be treated as a bucket, otherwise a customer won't be able to purchase more subscriptions and add them to the same activation key.

This is a bug, not an RFE IHMO.

Would it be possible to get some input from users on exactly what they were hoping to accomplish when they hit these errors? I have a suspicion that the actual goal here is "get me these products, I don't care what pools they come from". Per comment #4 I think forcing the user to add pools in this scenario may be missing the point for what they actually wanted to accomplish and just make things more complex and harder to understand.

I am presently not keen on the grouping of pools approach, today activation key pools are an AND operation, adding the concept in for an OR is going to add a lot of complexity, in UI, for the user who has to setup those keys (or understand them if we attempt to figure this out automatically), and for us to apply them. I suspect it will be the source of a lot of bugs and confusion.


I definitely think something should be done to improve the current situation, but my proposal would be to:

- enhance candlepin to allow attaching SKU product IDs to keys.
- Satellite lists all unique SKUs (displaying the friendly product name) from pools available in the org, user attaches the product names they want to the key.
- enhance candlepin to treat these as products to satisfy in an autobind, the system will be given sufficient subscriptions to get it access to those SKUs.

This to me is what I suspect users who are hitting this actually want. We could enhance to let users attach engineering product IDs as well if this becomes desired. Key setup stays simple, candlepin is already virtually ready to accommodate this without significant additional complexity. Keys then have the ability to add the specific pools you want to apply, or the products you want to apply from everything is available, you don't care what pools are used.

We already have service level preference on keys, this would be respected when attaching the actual pools.

The only scenario I have heard which this would not satisfy is if the user actually literally wants to only use a subset of the pools they have available for a specific product, for some reason. If that is a hard requirement the above proposal will not work. 

I may be mistaken on this but it would be great to hear from users who hit these problems and see what they actually would find easiest.

At the customer I was at, we added some 'Red Hat Enterprise Linux w/ Smart Management' subscriptions to our manifest when we built the Satellite, and added those to an activation key.

A few days later, we wanted some more.  We added them through the customer portal, refreshed the manifest, and then added them to the AK.  Under the activation key those two things show up as two line items.

If the first bunch of 'Red Hat Enterprise Linux w/ Smart Management' was out of subscriptions a host would not register.

I think most customers would expect it to work that way. The underlying implementation doesn't matter too much to me, as long as I can add more subscriptions later (even regardless of SLA, as mentioned in comment #1, part 2).

In the last paragraph, I meant most customers would *not* expect it to work that way.

What @sbenjamin says, not having to attach pools to AKs, but SKUs instead would be a feature, not bug

Just ran into this.

We ran out of subscriptions in our manifest, so generated a new manifest with more subscriptions.

We then added the 10 new subscriptions to our activation keys.

However, the activation keys still report as all subscriptions used, despite having 10 available.

This is a bug, there is no other way about it.

It is also a clear regression from how activation keys worked in sat5.

A use-case I've encountered is around "unlimited guest" guest subscriptions, like the "Red Hat Enterprise Linux for Virtual Datacenters" subscription. When this subscription is in use, a pool is created for each hypervisor. 

What I would like to accomplish is to have one Activation Key which would attach a newly provisioned VM to the correct guest pool, no matter which hypervisor it ends up on.

Moving to POST since upstream bug http://projects.theforeman.org/issues/6939 has been closed
-------------
Christine Fouant
Applied in changeset commit:katello|66b1a73dd0cee4c0053fe8b32073b78a9d5f2afa.

*** This bug is verified in upstream.  This fix should eventually land in future downstream builds ***

Version Tested:
RHEL66 / RHEL 7

katello-installer-2.1.0-1.201412071742git114a910.el6.noarch
pulp-katello-0.3-3.el6.noarch
katello-default-ca-1.0-1.noarch
katello-repos-2.1.1-1.el6.noarch
ruby193-rubygem-katello-2.1.0-1.201412101236git4521c2f.el6.noarch
katello-certs-tools-2.0.1-1.el6.noarch
katello-server-ca-1.0-1.noarch
rubygem-hammer_cli_katello-0.0.6-1.201412101306git7d5e313.git.0.44a4586.el6.noarch
katello-2.1.0-1.201411061509gitb0b8f43.el6.noarch
katello-ca-consumer-qe-foreman-rhel66.usersys.redhat.com-1.0-1.noarch

*** Bug 1161323 has been marked as a duplicate of this bug. ***

This bug is slated to be released with Satellite 6.1.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2015:1592