Challenges with SCA Migration

Hi,

We’re long time users of Foreman/Katello (first deployed in 2016) to manage our estate of CentOS and AlmaLinux hosts.

The forced removal of the old subscription model in favour of SCA has completely caught us out. We briefly turned it on and then quickly turned it off again. We’re now stuck on 3.9/4.11 as we try to figure out a way forward with SCA.

How we have traditionally worked is as follows: -

  • A custom product per EL version (8.10, 9.1, 9.2, 10.0 etc)
  • An additional custom product per EL major version that contains various third party and in-house developed tools and utilities.
  • A large number of additional custom products containing third party and in-house developed software. (e.g. Kafka, Elasticsearch, RabbitMQ, etc).
  • Hosts are grouped into host collections based on environment and EL major version. e.g. EL9 pre-prod, EL8 production, etc.
  • The EL product repos are synced once a week with the public mirrors, we do not generally use content views.
  • When a new minor version of EL is released (e.g. 9.7) we use the bulk tool against a host collection to remove the subscription to the previous version and add the new version.

So in summary, every host is subscribed to the product for its major.minor version of EL, a “tools” product/repo targeting the EL major version and optionally one or more additional products containing third party or in-house software.

It seems pretty clear to me that we cannot lift and shift this way of working into SCA.

It seems the behaviour of SCA is to subscribe every custom product to every host but with the repos disabled by default. But there is no bulk action tool that I can see that operates on the repo enable/disable switch at the host collection level. So I cannot go into a host collection and say disable AlmaLinux 9.6 on all hosts and enable AlmaLinux 9.7.

The fact that hosts are subscribed to all repos also caused issues for us in that we use -–disablerepo and –-enablerepo flags to dnf with some wildcards. With subscriptions this provided a limit on what repos could be enabled, but with SCA we could enable all sorts of random repos with unexpected side-effects.

I looked at implementing content views instead, the new rolling views looked promising, but ultimately hit a dead end. They cannot account for the variable list of repos required on hosts within the same host collection.

I hope that makes some sense. Would be interested to hear what others thought are on how to manage large estates with custom products. As it stands at the moment we are stuck on 3.9 as the last version to support the traditional subscription model.

With the new UI: Hosts > All Hosts

Search for “host_collection = my-host-collection”

Select all matching hosts

in the menu, click Content > Repository Sets

Set as you wish.

In the legacy UI:

Hosts > Content Hosts

Search for “host_collection = my-host-collection”

Select all matching hosts

Click Select action > Manage Repository Sets

You can do this in the web UI via the procedure I outlined above. But this use case seems a better match for content views and lifecycle environments than repo enablement/disablement.

Thanks for that. I think content views are the way to go. Just need to play around some more in my test instance.

1 Like

Keep in mind you end up having to do both, because once you’re on an up-to-date Katello, new Custom repos will not be enabled by default, so you will have to both promote a CVV that has the new repos as well as enable those repos for all the hosts that need them (and add them to any relevant activation keys).