Bug 1423505

The use case that I believe you are trying to accomplish is

When registering a guest:

- I want to ensure that it consumes the subscription of its hypervisor. 
- I want to do this without requiring the admin to attach every derived SKU (of each hypervisor the guest might be hosted on) to the activation key. 


That can be accomplished with an Activation Key with no subscriptions attached (absolutely zero. No Red Hat subs. No Custom Subs)+ auto-attach = true. This will allow you to register guests on their respective hypervisors without having to attach the derived subs to the key. 

This is documented in use case #2 of this doc (https://access.redhat.com/blogs/1169563/posts/2867891) 


The interesting twist is adding in custom products. 

According to Satellite's UI:

"When Auto Attach is enabled, registering systems will be attached to all associated custom products and only associated Red Hat subscriptions required to satisfy the system's installed products."

If I understand you correctly, you are stating that if you were to create a key with auto-attach = true AND custom products attached, that they are not. 

This would be counter to the statement in the UI, and further investigation would be required. 

Generally, I recommend putting custom products on their own activation key anyway because since they behave differently from Red Hat products, it makes sense to separate them. Plus I am a big fan of the UNIX model of doing 'one thing well'. 


I am hesitant to support adding a new field to an activation key to 'add any Derived SKU' as I believe that the use case that it would solve is already solved today.

@Rich: yes, if auto-attach is set to true and custom products are added, no Red Hat products are attached. 
So it seems the UI wording could be better - please test & confirm what I saw if at all possible.

Using multiple activation might solve the use case indeed.

All custom products in an activation key will be attached, regardless of auto-attach true or false. If this is not the case then please file a BZ with reproducer steps.

(In reply to Tom McKay from comment #5)
> All custom products in an activation key will be attached, regardless of
> auto-attach true or false. If this is not the case then please file a BZ
> with reproducer steps.

Understood. The question is what is the expected behavior of Red Hat subscriptions in this scenario:

- User creates an activation key. 
- User sets key to auto-attach = true. 
- User associates a custom subscription. 
- User associated no/zero Red Hat subscriptions. 

Should:

[A] Only the custom product get attached. 
[B] Both the custom product AND a Red Hat subscription get attached

The wording in the UI is arguably unclear:

"When Auto Attach is enabled, registering systems will be attached to all associated custom products and only associated Red Hat subscriptions required to satisfy the system's installed products."


Based upon the reproducer below, it appears to be [A]

# Assume the following custom sub. 

[
  {
    "ID": 18,
    "UUID": "2c91809352db8ab10152db9c9c770d57",
    "Name": "Extra Packages for Enterprise Linux",
    "Contract": null,
    "Account": null,
    "Support": null,
    "Quantity": "Unlimited",
    "Consumed": 2,
    "End Date": "2046-02-05T17:10:15.000+0000",
    "Attached": 2
  },
]

# Create an AK, set the auto-attach = true & associate the custom sub. 
ORG=Example
hammer activation-key create --organization "$ORG" --name 'ak-test-custom' --content-view RHEL7_w_EPEL --lifecycle-environment Library
hammer activation-key update --organization "$ORG" --name 'ak-test-custom' --auto-attach true
hammer activation-key add-subscription --organization "$ORG" --name "ak-test-custom" --subscription-id 18


# verify the key is setup as desired. 
hammer activation-key info --organization "$ORG" --name ak-test-custom
Name:                  ak-test-custom
ID:                    23
Description:           
Host Limit:            Unlimited
Auto Attach:           true
Lifecycle Environment: Library
Content View:          RHEL7_w_EPEL
Host Collections:


hammer --output json activation-key subscriptions --activation-key ak-test-custom --organization "$ORG" 
[
  {
    "ID": 18,
    "Name": "Extra Packages for Enterprise Linux",
    "Attached": null,
    "Quantity": null,
    "Start Date": "2016-02-13T17:10:15.000+0000",
    "End Date": "2046-02-05T17:10:15.000+0000",
    "Support": null,
    "Contract": null,
    "Account": null
  }
]


# On a client:

# subscription-manager register --org Example --activationkey ak-test-custom
The system has been registered with ID: cd762202-8e2d-4ace-9a65-0ec60d8a9921 

Installed Product Current Status:
Product Name: Red Hat Enterprise Linux Server
Status:       Not Subscribed

Unable to find available subscriptions for all your installed products.
# subscription-manager list --consumed
+-------------------------------------------+
   Consumed Subscriptions
+-------------------------------------------+
Subscription Name:   Extra Packages for Enterprise Linux
Provides:            Extra Packages for Enterprise Linux
SKU:                 1455383415560
Contract:            
Account:             
Serial:              2355506871675640933
Pool ID:             2c91809352db8ab10152db9c9c770d57
Provides Management: No
Active:              True
Quantity Used:       1
Service Level:       
Service Type:        
Status Details:      Subscription is current
Subscription Type:   Standard
Starts:              02/13/2016
Ends:                02/05/2046
System Type:         Physical



Lastly, since we commonly recommend to users to create an AK with no Red Hat Subs attached with the intent of getting either the derived SKU or 24h unmapped guest pool, it is not unreasonable for them to believe that a key with no Red Hat subs attached (regardless of the presence of custom subs) will behave exactly the same. 

They currently do not.

My recommendation would be to:

- change the behavior such that activation keys with no Red Hat subscriptions will behave the same regardless of the presence of a Custom subscription. 

OR 

- update the wording in the Satellite UI to make this distinction more obvious. 

I would strongly prefer the former. Also, assuming that the former is completed, I believe it would also satisfy François' request in the description.

For the record, "activation keys set to auto-attach must behave the same regardless of the presence of a custom subscription" would indeed satisfy my request.

If we cannot do that the wording in the UI should be adapted.

Currently in candlepin, when registering with a key that has autoattach=true and a set of subscriptions associated with the key (regardless of being custom or not), only the set of subscriptions associated with the key will be considered by the auto-attach process.

(In reply to Michael Stead from comment #9)
> Currently in candlepin, when registering with a key that has autoattach=true
> and a set of subscriptions associated with the key (regardless of being
> custom or not), only the set of subscriptions associated with the key will
> be considered by the auto-attach process.

Fair enough, but I seem to (mis)remember that it didn't use to work this way. That is, an activation key with autoattach=true + Custom Subs + 0 Red Hat sub would still end up with an unreported guest getting an temp unmapped pool. 

(However, I could be misremembering).

The net effect is that a user would need an additional activation key for custom products, and present them all at registration time. This is what we recommend in Subscription-manager for the former Red Hat Network User: Part 9 - A Case Study with activation keys.(https://access.redhat.com/blogs/1169563/posts/2867891)


Also, it is not entirely clear the intended/expected behavior of keys in the UI (https://bugzilla.redhat.com/show_bug.cgi?id=1527227)

After discussing this with the team, we won't implement this functionality. Activation keys are confusing enough as is, and it doens't make sense to have a singular key behave in multiple ways. (and potentially changing the behavior of already deployed keys).

We are closing this bug in favor of  [RFE] add additional info to activation key subscription attachment page (https://bugzilla.redhat.com/show_bug.cgi?id=1527227) with longer term changes to subscription intent being delivered with [RFE] Subscription-Intent:   Allow a user to express the intent of how a subscription should be used,   using a rules based syntax (https://bugzilla.redhat.com/show_bug.cgi?id=1401106)

*** This bug has been marked as a duplicate of bug 1401106 ***

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days