Bug 1387718

Summary: [RFE] When "No activation key was applied successfully." expose all the reasons to the sub-man client.
Product: [Community] Candlepin Reporter: John Sefler <jsefler>
Component: candlepinAssignee: candlepin-bugs
Status: NEW --- QA Contact:
Severity: unspecified Docs Contact:
Priority: medium    
Version: 2.0CC: candlepin-bugs, csnyder, khowell, ktordeur, qianzhan, redakkan, weiliu
Target Milestone: ---Keywords: FutureFeature, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1383927 Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1383927    
Bug Blocks:    

Comment 1 John Sefler 2016-10-21 16:16:26 UTC
I am opening this RFE in response to the poor user experience cloned above from Bug #1383927

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.

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'."

Here is where I'd like to see an enhancement... 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'.

Note that the list of reasons could be long especially when there are multiple keys and multiple pools in each key.