Allow SLE Micro system to access free SLES repositories

[jesusbv]

Description

A SLE Micro system must have access to all free SLES repositories

This Fixes bsc#1230419

• Related Issue / Ticket / Trello card: https://bugzilla.suse.com/show_bug.cgi?id=1230419

How to test

On a SLE Micro PAYG instance, configured according to the documentation to use Podman,
running zypper lr inside the container should show SLES repositories

On a SUMA 5.0 instance, activating SUMA 4.3 should also activate the recommended SLES repositories

Change Type

Please select the correct option.

• Bug Fix (a non-breaking change which fixes an issue)
• New Feature (a non-breaking change which adds new functionality)
• Documentation Update (a change which only updates documentation)

Checklist

Please check off each item if the requirement is met.

• I have reviewed my own code and believe that it's ready for an external review.
• I have provided comments for any hard-to-understand code.
• I have documented the MANUAL.md file with any changes to the user experience.
• If my changes are non-trivial, I have added a changelog entry to notify users at package/obs/rmt-server.changes.

Review

Please check out our review guidelines
and get in touch with the author to get a shared understanding of the change.

[digitaltom]

You are defining, based on the product identifier of the registered base product, to infer which other products / repositories the system can use. That works, but is a lot of manual setup.

Maybe there is an automatic way to find out that information, in the way how SCC is doing this:
In SCC, the used subscription of the base product has a list of product classes. The system then has 'permission' to use all products that have a product class of that list. Example: a SUMA subscription includes the product classes of SLES (7261), SLE Micro (MICROOS-X86).

We have a manual config to build that connection for test subscriptions: https://github.com/SUSE/happy-customer/blob/master/glue/config/multi_product_classes.yml

Just an idea, maybe this is a less manual, and more aligned with SCC way how to define access permission.

[jesusbv]

You are defining, based on the product identifier of the registered base product, to infer which other products / repositories the system can use. That works, but is a lot of manual setup.

Maybe there is an automatic way to find out that information, in the way how SCC is doing this: In SCC, the used subscription of the base product has a list of product classes. The system then has 'permission' to use all products that have a product class of that list. Example: a SUMA subscription includes the product classes of SLES (7261), SLE Micro (MICROOS-X86).

We have a manual config to build that connection for test subscriptions: https://github.com/SUSE/happy-customer/blob/master/glue/config/multi_product_classes.yml

Just an idea, maybe this is a less manual, and more aligned with SCC way how to define access permission.

@digitaltom It is a good idea, however, when I tested that, the subscription identifier in the activated products for the stand-alone SLE Micro (not SUMA) system was nil

[bear454]

Is there no positive test here we can do? It feels inefficient to say "if it's not sles maybe it's sle-micro".