Bug 1121768

Please make this a globbing capable feature. So the following should work too:

# subscription-manager attach --auto --provides *Collecitons*
# subscription-manager attach --auto --provides "*Red Hat Software Collecitons*"

Acking 7.1

(In reply to Rich Jerrido from comment #0)
> [Proposed] Example #2:
> [root@satellite ~]# subscription-manager attach --auto --provides 'Red Hat Software Collections (for RHEL Server)'
> 
> Would attach an appropriate subscription that provides the 'Red Hat Software Collections (for RHEL Server)' product.

In my opinion it is wrong to include the "--auto" option in the syntax of this proposed example.  The meaning of "--auto" is to attach subscriptions that provide a product that is already installed on your system.  In this example, the 'Red Hat Software Collections (for RHEL Server)' is not already installed on the system and therefore the attach --auto request will do nothing.  Instead, the syntax of this example should be simplified to...

[root@satellite ~]# subscription-manager attach --provides 'Red Hat Software Collections (for RHEL Server)'

Note: Since multiple available subscription pools may provide 'Red Hat Software Collections (for RHEL Server)', the attachment should minimally match the service level (if set on the consumer) and attach from the first pool found that provides 'Red Hat Software Collections (for RHEL Server)'

Note: If using wildcards in this example, you may not get what you want when there are multiple pool candidates.

re: the usage of '--auto'. I may have overloaded the term a bit.

The use case that I am thinking of is less about attaching to subscription to an existing product, but more of 'I know I need RHSCL, I currently don't have it and I don't really care which pool provides it, as long as it matches (based on facts, SLA preference, etc)'. So the latter part would happen 'automatically', though it is not, in fact, 'auto-attach'. That was my (overloaded) usage of '--auto', and I'll refrain from that usage.

Solution for bug #1146125, which will be a new --matches option in the subscription-manager list command, will search for pools matching a given globbing pattern (* and ? supported) in a variety of fields, including provided product names as well as their engineering product IDs. 

I'm going to propose this be closed as a duplicate as I'm afraid "subscription-manager attach --auto --matches "*Collections*" would be confusing.

Firstly today, subscription-manager attach --auto will search out subscriptions matching your currently installed products and automatically attach them for you. The "healing" feature runs the same code and is enabled by default, thus it's safe to assume that if what you wanted with this example were already provided by an installed product, you wouldn't need to be searching for subscriptions.

I think the use case intended is "I don't have an installed product for this, I want to search for pools which provide something new and automatically install them." But where would this CLI option go? We probably shouldn't overload "attach  --auto" in this manner to mean something completely different if --matches is added.

Additionally if we did find a place to put it, we now have to start thinking about what happens if you get multiple matches. We'd have to make assumptions about what you intended and which to use, and what happens if stacking is involved or partially involved. 

Overall adding this to auto would almost certainly result in a lot of unpredictable or unexpected behavior. As such we're proposing to close this and see how we make out with --matches for now.

Rich if you feel strongly against please feel free to re-open.

*** This bug has been marked as a duplicate of bug 1146125 ***