Can you provide some additional context? Specifically:

1. what about the listing consumed pools is problematic?
2. are we at all concerned about the case of an org moving from entitlement -> SCA -> entitlement?
3. does such a feature need to be backward compatible with all existing clients, or could this be a case where existing clients function as they do, and newer clients remove them on refresh?


While this RFE seems simple on the surface, there are some underlying design choices and limitations which pose problems. Namely, some organizations are large enough that a massive revocation could take 10+ minutes and stall out the response time on the initial switch to SCA. Doing it on a per-system basis when "subscription-manager refresh" is invoked is definitely more approachable from a response time standpoint, but has design limitations in that an existing, shared endpoint will inherit unrelated and, perhaps, unexpected behavior [1]. We can work around that by adding a parameter or a new endpoint for this cleanup, but then the client would need to be updated to invoke it as appropriate.

We have other options in terms of how to approach such a feature, but we would like to know more about the issues encountered that are driving this request before we design and implement something that may not work as users want or expect.



[1] In terms of client communication with Candlepin, currently subman refresh only invokes the "fetch certificates" operation, which, if the RFE were implemented exactly as worded today, would also revoke/delete entitlements for the system if the system's org is operating in SCA mode. Callers would need to be aware of this side effect; which would be strange for a GET request for certificates to perform, even with explicit documentation.

Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team.  Thank you.

This has actually been implemented on the Candlepin side, but our automation did not catch/update the BZ.
For this to work however, the client side (subscription-manager) also needs changes. You can track that work by following the 2 'blocks' BZ links,
and from there, follow the jira links (since RHEL has moved to using jira now):
https://issues.redhat.com/browse/RHEL-7192
https://issues.redhat.com/browse/RHEL-7195

Based upon feedback during auto-closure, leaving this bugzilla open a while longer for additional investigation; however, it may be closed in a future iteration.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "SAT-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.

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