Bug 1126924 - [RFE] some form of activation key that contains subscription groups rather than exact subscriptions needed
Summary: [RFE] some form of activation key that contains subscription groups rather th...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Subscription Management
Version: 6.0.4
Hardware: Unspecified
OS: Unspecified
high
high vote
Target Milestone: Unspecified
Assignee: Christine Fouant
QA Contact: jcallaha
URL: http://projects.theforeman.org/issues...
Whiteboard:
: 1123668 1132374 1161323 (view as bug list)
Depends On:
Blocks: 1122832 1132363 sam20-tracker 1139277
TreeView+ depends on / blocked
 
Reported: 2014-08-05 15:24 UTC by Tom McKay
Modified: 2019-08-15 03:55 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-08-12 05:13:22 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:1592 normal SHIPPED_LIVE Important: Red Hat Satellite 6.1.1 on RHEL 6 2015-08-12 09:04:35 UTC

Description Tom McKay 2014-08-05 15:24:40 UTC
As act keys work today, all subs associated will be assigned to the registering host. If any fail to attach, the registration itself fails.

There are use cases, however, where a group of subs are useful.

1. Given two of the same subscription but with different quantities (RHEL quantity 1, and RHEL quantity 60), I'd have to make two separate act keys. Ideally I would simply associate those two RHEL to one key and have the host use whatever was still available.

2. Given two subs with different SLA, I would need to create two act keys. Instead, since the hosts themselves can have SLA, I could attach both and the proper sub would be chosen from the group.

Comment 1 Tom McKay 2014-08-05 15:24:41 UTC
Created from redmine issue http://projects.theforeman.org/issues/6939

Comment 3 Ivan Necas 2014-08-06 07:05:35 UTC
*** Bug 1123668 has been marked as a duplicate of this bug. ***

Comment 4 Matej Kollar 2014-08-07 10:56:33 UTC
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.

Comment 5 Stephen Benjamin 2014-08-21 10:13:58 UTC
*** Bug 1132374 has been marked as a duplicate of this bug. ***

Comment 7 Stephen Benjamin 2014-08-21 10:16:58 UTC
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.

Comment 8 Devan Goodwin 2014-09-04 18:44:48 UTC
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.

Comment 9 Stephen Benjamin 2014-09-04 19:19:03 UTC
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).

Comment 10 Stephen Benjamin 2014-09-04 19:20:22 UTC
In the last paragraph, I meant most customers would *not* expect it to work that way.

Comment 11 Ivan Necas 2014-09-04 19:31:52 UTC
What @sbenjamin says, not having to attach pools to AKs, but SKUs instead would be a feature, not bug

Comment 12 Nick Strugnell 2014-11-27 14:43:34 UTC
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.

Comment 13 David Juran 2014-12-01 16:08:10 UTC
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.

Comment 14 Bryan Kearney 2014-12-02 23:03:13 UTC
Moving to POST since upstream bug http://projects.theforeman.org/issues/6939 has been closed
-------------
Christine Fouant
Applied in changeset commit:katello|66b1a73dd0cee4c0053fe8b32073b78a9d5f2afa.

Comment 15 jcallaha 2014-12-12 21:12:16 UTC
*** 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

Comment 16 Christine Fouant 2014-12-18 20:53:59 UTC
*** Bug 1161323 has been marked as a duplicate of this bug. ***

Comment 17 Bryan Kearney 2015-08-11 13:37:07 UTC
This bug is slated to be released with Satellite 6.1.

Comment 18 errata-xmlrpc 2015-08-12 05:13:22 UTC
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


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