Subscription Matching details

[kurzandras]

Dear all,

I would like to ask for more details about the Subscription Matching feature. I have checked the documentation, but I could not find any details about the process.

I have a SUSE account on which there are quite a few types of subscriptions and my problem is that I am unable to assign SLES systems to the desired subscriptions. For example on certain hosts Uyuni thinks that they belong to L3 priority sub with live patching, but this is not the case. When I try to "pin" hosts, the correct/desired subscription does not appear in the list.

I have tried to uninstall all the products from the SLES machines, now only the Base System module is installed, but for some reason it still does not work.

My questions are:

• What kind of things determine the decision making process of Uyuni when it comes to subscription matching? (I thought only the installed OS version and products, but it seems this is not the case)

• Does Uyuni report the subscription matching status back to SUSE in any way?

• Is it possible to just ignore the subscription matching errors or disable this feature completely?

Any help/information is really appreciated! Thanks very much in advance!

[mcalmer]

Subscription Matching just try to find a "best match" to give the customer an idea if he has enough subscriptions. Some attributes of a subscription cannot be taken into account automatically, like the support type (Standard or Priority subscription).

What kind of things determine the decision making process of Uyuni when it comes to subscription matching? (I thought only the installed OS version and products, but it seems this is not the case)

From the system we use the installed products, the number of CPUs (of the host system mostly) or vCPUs (for some types of subscriptions).
When it comes to virtual machines, the hardware information of the "host" are important as some types of subscriptions have "unlimited virtualization". They are assigned to the host, and all VMs can freely use them. This is also the reason why it is essential, that Uyuni knows about host <=> virtual machine relations.

Also take into account that most subscriptions are only for 1-2 Sockets. If you have a server with 4 Sockets, you need 2 subscriptions for it.
If the subscription is for 1-2VMs, it is important that they run in the same environment. This can mean on the same host, in the same VMware group or in the same cloud region. If this information is not available, such a subscription is assigned only to 1 VM.

Pinning is currently only a "hint" for the matcher to prefer that assignment. But if the matcher find a better overall result when it ignore the pin, it will do so.
This is currently under discussion if the pin should get a higher rating.

Does Uyuni report the subscription matching status back to SUSE in any way?

No

The raw data about registered systems are reported back to SCC. You can see them in the SCC Web UI.
The result of the matching is only local on the Uyuni Server.

Is it possible to just ignore the subscription matching errors or disable this feature completely?

It cannot be disabled, but a human can ignore everything.

In the end subscription matching should help the admin and it does not replace an audit.