Bug 1383927

Created attachment 1209499 [details]
The rhsm.log

Can we see the contents of /etc/rhsm/facts/custom.facts? We suspect the failure to apply the activation key stems from it's contents.

The content of custom.facts is: 
{"cpu.cpu_socket(s)":"4"}

[root@hp-z220-15 facts]# subscription-manager unregister
System has been unregistered.
[root@hp-z220-15 facts]# subscription-manager register --org=7967630 --activationkey=liuwei
No activation key was applied successfully.
[root@hp-z220-15 facts]# cat custom.facts 
{"cpu.cpu_socket(s)":"4"}
[root@hp-z220-15 facts]#

This is working as designed as the pool will work only for virtual guests.

As shown below, I can reproduce the failure when attempting to use this activation key from a physical system...

[root@jsefler-rhel7 ~]# cat /etc/rhsm/facts/custom.facts 
{"cpu.cpu_socket(s)":"4","virt.is_guest":"false"}
[root@jsefler-rhel7 ~]# subscription-manager register --org=7967630 --activationkey=liuwei
No activation key was applied successfully.



And successfully register with this key from a virtual system...

[root@jsefler-rhel7 ~]# cat /etc/rhsm/facts/custom.facts 
{"cpu.cpu_socket(s)":"4","virt.is_guest":"true"}
[root@jsefler-rhel7 ~]# subscription-manager register --org=7967630 --activationkey=liuwei
The system has been registered with ID: 03b40b2f-908b-49e8-8834-58c47249a6b5 

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



Therefore the pool attached to the key is restricted to physical_only systems.

(In reply to John Sefler from comment #8)
> Therefore the pool attached to the key is restricted to physical_only
> systems.

Oops, Typo above, should have said...
Therefore the pool attached to the key is restricted to virt_only systems

and you can see that in the pool attributes of comment 3

The problem with this bug is that the user experience is poor.  The user is attempting to use an activation key, but because none of the pools in the key were applied successfully, no registration occurs.  Unfortunately the reason that no pool was applied successfully is hidden from the user.  It is buried in the candlepin logs that the user does not have access to.

This behavior was a conscious decision introduced in candlepin commit https://github.com/candlepin/candlepin/commit/bcb4b8fd8ee009e86fc9a1a20b25f19b3dbe6b2a

Part of the goal of that ^ commit was to make activation keys be more forgiving and succeed so long as at least one pool was attached and hide from the user all the pools that were not attached.  This was a request from Satellite who wanted to maintain fewer keys that contained more pools (one of which should apply).  So long as one pool was attached, then registration with the activation key was considered a success.

That is why this bug was CLOSED NOTABUG

Prior to this commit a stderr message was output to the user informing why each of the pools failed to attach.  In the case of the scenario in comment 0, the user would have seen in stderr  "Pool is restricted to virtual guests: '8a99f9815771b1a301577550acd808ad'."

In my opinion, I'd like to see this bug re-opened as an RFE that requests... If "No activation key was applied successfully", please revert back to some of the original behavior that listed out all the failure reasons why each pool in the keys was not attached?  The output might look like this...

[root@jsefler-rhel7 ~]# subscription-manager register --org=7967630 --activationkey=liuwei
No activation key was applied successfully.
Pool is restricted to virtual guests: '8a99f9815771b1a301577550acd808ad'.