Description of problem: "subscription-manager auto-attach" takes the "first" available entitlement offering the required RHEL subscription. I saw a Datacenter Subscription on a standalone system (SFDC 01627925, account 818035), which confused the customer. Version-Release number of selected component (if applicable): subscription-manager-1.15.9-15.el7.x86_64 How reproducible: Always Steps to Reproduce: 1. Choose an account with a large amount of different entitlements 2. Run subscription-manager auto-attach Actual results: A random entitlement is taken. Expected results: A useful subscription attached. Additional info: From Red Hat point ov view, the most expensive entitlement should be applied (I think about RHEL Premium, RHEL Standard, Developer subscriptions). From Customer point of view, the least expensive entitlement should be applied. Datacenter entitlements or products with included RHEL subscriptions (OpenShift, OpenStack, Satellite, ...) should never be applied automatically.
is syspurpose in rhel 8 a first step towards the goal of this bz? https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#syspurpose
(In reply to Klaas Demter from comment #7) > is syspurpose in rhel 8 a first step towards the goal of this bz? > > https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#syspurpose Sort of. As RHEL8 doesn't have variants (Server/Workstation/ComputeNode), we needed a means to allow the user to describe the usage of the system. That data (the system purpose) is fed to the subscription tools (sub-man/Candlepin) as will be used as a heuristic to better attach subscriptions. If (when?) we chose to implement truly user-specified rules (see also bz1401106), syspurpose would be one of the many parameters the user can use.
With the advent of Simple Content Access (https://access.redhat.com/articles/simple-content-access), this feature is rendered obsolete.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days