Red Hat Bugzilla – Bug 885763
[RFE] idea to avoid abandoned consumers holding unproductive entitlements
Last modified: 2016-09-08 16:08:16 EDT
Description of problem:
After listening in an a GSS meeting where they were discussing customer issues, I heard this complaint "how come all my entitlements are being consumed so fast?" One answer has to do with the instructions that I heard one of the GSS folks describe... "run subscription-manager clean, and then register with --force".
The problem with this instruction is that there are dirty consequences of using clean. Primarily, the old consumer (who has already been granted entitlements) is NOT deleted server-side by the system's actions to "run subscription-manager clean, and then register with --force". Instead, a new consumer is created who will subsequently consume more entitlements thereby leaving the former consumer abandoned on the server holding onto unproductive entitlements.
When a consumer registers to candlepin, it sends up it's system facts...
Search through the existing consumers for one having the same mac_address
(I'm looking for one fact or a combo to uniquely identify this unit)
If a match is found, throw an exception...
"A unit with the same <mac_address foo> has been registered previously as
consumerid <uuid>. Try registering with --consumerid to regain
lost entitlements, or try register with --force to delete the old
If the user registers with --consumerid, all should be good already.
If the user registers with --force, then candlepin needs to be updated to...
delete the previous consumer thereby putting its entitlements on the CRL
and adding its quantity back into the pool.
In the land of QE, I also witness entitlements being consumed and never released as systems are registered with the stage candlepin and later re-built without ever having been unregistered.
*** Bug 991563 has been marked as a duplicate of this bug. ***
A con of the proposals is that it increased the cost of registration calls. There are also a lot of edge cases (ex. cloning VMs or OpenStack use-cases). An alternative that we are considering is adding warnings to the clean command. For example, "Are you sure you want to clean this system? You will orphan all entitlements attached to this unit."