Description of problem: This is not a duplicate, but rather it *seems* to be a regression since the fix for BZ#1274693 of the same description. The fix for BZ#1274693 was reported as fixed in https://access.redhat.com/errata/RHBA-2016:1501 (v6.2.0) However, this has been observed on a fully updated 6.2.12 Satellite Version-Release number of selected component (if applicable): v6.2.12 How reproducible: Always Steps to Reproduce: 1.) Create an activation key with *only* a custom product subscription attached to it. # hammer activation-key info --name custom --organization myorg Name: custom ID: 5 Description: Host Limit: Unlimited Auto Attach: true Lifecycle Environment: dev Content View: rhel7 Host Collections: # hammer activation-key subscriptions --name custom --organization myorg ---|------|----------|----------|---------------------|---------------------|---------|----------|-------- ID | NAME | ATTACHED | QUANTITY | START DATE | END DATE | SUPPORT | CONTRACT | ACCOUNT ---|------|----------|----------|---------------------|---------------------|---------|----------|-------- 8 | epel | | | 2017/10/11 19:56:18 | 2047/10/04 19:56:18 | | | ---|------|----------|----------|---------------------|---------------------|---------|----------|-------- 2.) Register a server using that activation key (expecting the auto-attach to give it the temporary subscription. (i.e. "Status Details: Guest has not been reported on any host and is using a temporary unmapped guest subscription.") Actual results: The registered client will get *only* the subscription for the custom product, and will not get the temporary subscription. (Manually clicking the "Run Auto Attach" from the Content Host's page WILL run auto attach and attach the temporary subscription). Expected results: The registered client should get a subscription based on auto-attach Additional info: If I remove the custom subscription from that activation key (so there are no subscriptions attached), and register a server, the registered server WILL get the temporary subscription
Created redmine issue http://projects.theforeman.org/issues/21790 from this bug
Custom products cannot have temporary subscriptions. They are always physical, even if the client is a guest of a hypervisor. I'm closing this as it seems to be working as intended.
Perhaps there was a misunderstanding. The product that is not being granted a subscription is RHEL. It is just the presence of a unrelated custom product that prevents the auto-attach from running and attaching the RHEL subscription. But then manually clicking "Run Auto-attach" DOES attach the temporary subscription. There is no desire to have the temporary subscription attach based on the custom product. The custom product appears only to be a trigger for this situation. A) Server registered with activation key that has NO subs assigned whatsoever. Result - RHEL gets its temporary or VDC subscription. B) Server registered with activation key that has an unrelated custom subs. Result - RHEL does not get it's temporary or VDC subscription (unless manually clicking auto-attach).
I see. I'll reopen and investigate. Sorry for the misunderstanding.
I am able to reproduce this on 6.2.z and 6.3.
# # empty activation key # subscription-manager register --org="Default_Organization" --activationkey=ak1 --force Unregistering from: centos7-devel.example.com:443/rhsm The system with UUID e851f5d7-b208-405e-82a5-3dcd0f3f9d97 has been unregistered All local data removed The system has been registered with ID: f35cfca2-b7fb-4e94-990e-17a473187ba8 Installed Product Current Status: Product Name: Red Hat Enterprise Linux Server Status: Subscribed # # activation key with custom product/sub # subscription-manager register --org="Default_Organization" --activationkey=ak1 --force Unregistering from: centos7-devel.example.com:443/rhsm The system with UUID f35cfca2-b7fb-4e94-990e-17a473187ba8 has been unregistered All local data removed The system has been registered with ID: 56c22fd9-1473-47f0-aef7-3afb242fe3f4 Installed Product Current Status: Product Name: Red Hat Enterprise Linux Server Status: Not Subscribed Unable to find available subscriptions for all your installed products.
This is now a duplicate of [1]. Auto-attach is running in candlepin, but the RHEL subscriptions are being skipped. Comments from [1] indicate that a solution to this problem will also solve the issue in [1]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1423505
Rich, this appears to be working as designed. The customer created an activation key that specified specific pools to use which did not include any rhel pools. The pools from the activation key were attached. What are your expectations in this case?
I can perhaps clarify the customer's expectations with regards to registering a RHEL server. (but not clearing the NEEDINFO) Using the above configuration with a VM using an activation key that has only a custom product.... 1) At registration time -> auto-attach does not appear to be attempted, or else the client would get the temporary unmapped guest subscription.. 2) At any point after -> manually clicking auto-attach works as expected and attached the temporary unmapped guest subscription. 3) Or waiting up to /etc/rhsm/rhsmcertd/:${autoAttachInterval} minutes (default 1440), rhsmcertd will trigger an auto-heal which gives the temporary unmapped subscription. So the client machines subscriptions are in such a state that the Satellite's auto-attach recognizes it needs to attach a subscription (in this case the temporary unmapped sub). But the only time it doesn't appear to attempt it at registration time. Customer expects that if the Satellite is going to take some auto-attach decision and action automatically up to 24 hours after the registration, it should probably be consistently doing it at registration time as well.
(In reply to Dylan Gross from comment #14) > I can perhaps clarify the customer's expectations with regards to > registering a RHEL server. (but not clearing the NEEDINFO) > > Using the above configuration with a VM using an activation key that has > only a custom product.... > > > 1) At registration time -> auto-attach does not appear to be attempted, or > else the client would get the temporary unmapped guest subscription.. > The type of key specified in comment #0 is effectively 'pick a matching subscription from the list specified'. Matching is done based on installed products (from /etc/pki/product* and system facts). To Barnaby's point in comment #13, this IS working as designed. None of the listed subscriptions match the installed products. This behavior is why we recommend using 2 activation keys to achieve desired effect. One key with absolutely ZERO subscriptions on it and auto-attach == true. No Red Hat subs. No Custom Subs. And use a second key to attach any custom products. Present both using subscription-manager register --activationkeys key1,key2 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), we state a STRONG preference for using multiple keys for this and other reasons. However, in the Satellite UI we state: "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.", which while true, is confusing. (and doens't unlock the temp sub). > 2) At any point after -> manually clicking auto-attach works as expected > and attached the temporary unmapped guest subscription. This is expected. > > 3) Or waiting up to /etc/rhsm/rhsmcertd/:${autoAttachInterval} minutes > (default 1440), rhsmcertd will trigger an auto-heal which gives the > temporary unmapped subscription. > ] This is also expected. > > So the client machines subscriptions are in such a state that the > Satellite's auto-attach recognizes it needs to attach a subscription (in > this case the temporary unmapped sub). But the only time it doesn't appear > to attempt it at registration time. > > Customer expects that if the Satellite is going to take some auto-attach > decision and action automatically up to 24 hours after the registration, it > should probably be consistently doing it at registration time as well. If you configure your keys as described above (and in the linked blog post), you can have this effect. As far as product level changes, we can potentially - make the wording in the UI much more clear (https://bugzilla.redhat.com/show_bug.cgi?id=1527227) - change the behavior of activation keys such that activation keys with no Red Hat subscriptions will behave the same regardless of the presence of a Custom subscription. (https://bugzilla.redhat.com/show_bug.cgi?id=1423505). But this would be net-new work. - be more prescriptive towards the usage of multiple activation keys. And to sanity check, 6.1 and early 6.2 work the same way, so this is definitely NOT a regression, so I am clearing the regression keyword
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 ***