Description of problem: In Satellite 6, we should be able to exclude certain subscriptions from been auto-attached. Some subscriptions should be used on very specific clients, but the user would like to keep leveraging the auto-attach feature for the other subscriptions. By example, when you have Openshift and Virtual Datacenter subscriptions available in your Organization, the auto-attach behavior could wrongfully attach the Openshift subscription instead of staying in a state of using "temporary unmapped guest subscription". The expected behavior would be to have the VM client using the "temporary unmapped guest subscription" until virt-who has reported the guest-mapping so the Guest VDC derived sku could be attach.
*** Bug 1524528 has been marked as a duplicate of this bug. ***
*** Bug 1435344 has been marked as a duplicate of this bug. ***
*** Bug 1718028 has been marked as a duplicate of this bug. ***
Thank you for your interest in Satellite 6. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this, please do not reopen. Instead, feel free to contact Red Hat Technical Support. Note, Simple Content Access and Subscription Watch may help. See https://access.redhat.com/documentation/en-us/subscription_central for more details.
As this bugzilla has stated, we are NOT implementing a functionality that will allow a user to exclude specific subscriptions from being auto-attached. And as far as WHY we aren't doing it, it is a matter of user experience. Today, with all of our tools, we have a very complex set of tooling (between subscription-manager, virt-who, and our backend tools) that requires the systems administrator to get more or less perfectly aligned in order to use content which they are already entitled to use. If they don't, they can't use our products to build systems, deploy apps, etc. Depending on how the user purchases (such as buying programs) and what they purchase (types of subscriptions / product mix), the 'number of required knobs to turn' to get it all setup are too many in number, and the amount of domain knowledge to get it all setup is pretty darn high. In short, the current model of subscription management is: - Time consuming - Overly complex, especially for the systems administration persona. - Business impacting. The penalty for 'getting it wrong' is high. We can choose to solve this in one of two ways: - Treat the symptoms by giving the user 'one more knob' to turn such as what this request for engineering was asking for. While this addresses the immediate need, it STILL requires the systems administrator to manage this complex system of tools, maintain the proverbial 'Ph.D in Red Hat Subscriptions', and is yet another Band-Aid™. - Treating the root cause. We (the Subscription Management Experience team) fundamentally believe that addressing subscription management from a persona/user experience perspective will net better results, AND is the most responsible investment. We have chosen to treat the root cause. To do this, Red Hat has introduced two new capabilities, Simple Content Access and Subscription Watch, which focus on 3 core experiences: - using the products [1] - continuing to use the products when you renew, remix, or grow [2], - and understanding what you've used regardless of where it runs (physical/virtual/public cloud/private cloud)[3] [1] - Simple Content Access removes the complexity of attaching entitlements. Just use the content you've paid for. If you need to enable EUS on a system and you have a valid sub for it, just enable the repo. No attaching entitlements, no pool IDs, no requirement to have a 'Ph.d in Red Hat Subs'. [2] - Simple Content Access makes it easy to renew, remix, and grow. By not having to attach entitlements, renewals and remixes are easy. Just import the new products into Satellite, versus having to *again* set up the complex system of subs, activation keys, and whatnot. [3] - Subscription Watch (the app running at cloud.redhat.com) makes it easy to understand what you've deployed. We (Red Hat) *do* have the 'Ph.d in Red Hat Subs', so we want to make it super easy (and transparent) to upload your inventory to us so that WE can tell you (via a cloud based app that we update frequently), your utilization (across all of your Satellites, systems registered to RHSM, and RHEL running in the public cloud [be it managed by Satellite or NOT]) In summary, our answer to the question of "Why can't I exclude this sub from auto-attach?" is "Why are we attaching subs to systems in the first place?" Frequently asked questions: Q: So how exactly does 'Simple Content Access' work? A: 'Simple Content Access' is an attribute that is set on a Satellite manifest which changes how Satellite behaves with regards to entitlements. When enabled, entitlements are not required to be attached to running systems. And those systems have access to whatever content is in their repositories (or Content View) provided that at least 1 subscription which provides access to them exists within the manifest/org. Simple Content Access is simply a technical facility to make it easier to use the items which you are already entitled to use. Example: I have a Satellite Org with RHEL & OpenShift subscriptions, the systems in that org can use RHEL & OpenShift content. Just run subscription-manager to enable whichever repositories that are needed, and install whatever you need to. There is no need to attach an subscription first. No pool IDs. No auto-attach skullduggery. Q: That sounds awesome! How do I get this capability? A: Red Hat is rolling Subscription Watch & Simple Content Access out to selected customers & partners and it will eventually be generally available to all. However, it can be requested by means of a support case OR by reaching out to your account team. This capability is currently available for Satellite 6.x users. This capability is under development for RHSM users and will be available at a later date. Q: Wait, if I don't have to attach entitlements to systems, how do I ensure that I do not deploy in excess of what I have valid subscriptions for? A: Within Satellite, you can set 'Content Host Limits' to set a maximum number of hosts that can be registered with an activation key. This can be used in conjunction with reporting to maintain accurate inventory of what has been deployed. Regarding reporting, it is STRONGLY recommended (but not required) to use Subscription Watch [4] as the reporting tool of choice, as it can be used in conjunction with [multiple] Satellite(s) and/or RHSM and provides a organization-wide view of utilization of subscriptions. You are welcome to use alternative tools, but we believe that your time is better invested elsewhere rather than counting Red Hat products. Let us do that. We're kinda good at it. Resources Please feel free to take a look at the following YouTube video which gives even more background as to why we have taken this direction [5]. Additionally, view our new documentation portal for Subscription management, Subscription Central [6], which should answer many other questions you may have. Lastly, please direct any specific questions to your Red Hat representative, as they are in the best position to answer any questions specific to your account(s). Rich Jerrido, RHC{E,{D,S}S,{V,S,}A} Principal Product Manager, Red Hat Subscription Management Experience Team [4] https://cloud.redhat.com/beta/subscriptions [5] https://www.youtube.com/watch?v=_77-QZAvXe4 [6] https://access.redhat.com/products/subscription-central