Katello products/cv/activation key organization


I’d like to ask how you organize your products / content views and activation keys?
e.g. products are OS types and versions
product “centos stream 8”, “centos stream 9”, rhel 8, rhel 9, and so on.

in those products we have according software repositories (appstream, epel, icinga, docker, influx, etc).

But there are also lots of “noarch” stuff or repos which are used in stream and rhel and so on.

my question: how do you organize your repositories, CV, CCV and activation keys in order to keep it simple and clear?

thanks very much!

First off: How you organize your content is very much up to personal preference and your personal use-cases. Here is how we currently do things:

(Disclaimer: We do not use SCA/Simple Content Access yet, this changes a lot of things is how content is handled and you might want to have a look at it before you start (re)organizing your content since it will be how things must be done in the future.)

For products, we pretty much have a mess. You can not (to my knowledge) change how RedHat content (and SLES content if you use SCCM plugin) is organized into products and we have a lot of those. For our custom products, we organize OSes in the " " style you suggested. Those products only contain the OS repos themself (so appstream, baseos, whatever else). For other software (like Puppet, EPEL, etc) we have one product per “vendor” (like one product “EPEL”, one “Puppet”, etc) that contains all the repos for all OS major versions.

On the CV side, we have one CV per OS Major Release per product, e.g. “RHEL 8”, “EPEL 8”, “Puppet EL8”, etc. We then have one CCV per OS Major Release, like “Our RHEL8”, that contains all the CVs for that OS Release.
We also had additional CCVs for systems that should consume special limited subscriptions like OpenShift, back when we had Openshift3 hosts that got managed by our Foreman.

Finally, for activation keys, we use multiple keys per system. In general, we have a variety of mutually exclusive keys per OS Major Release. For example, we have a key “Our RHEL 8-production”, that contains the information about the CCV to be used and the lifecycle environment to be assigned (“Our RHEL 8” and “production” respectively). This key is simply templated via ERB into the kickstart file’s subscription-manager command. In addition, we have one activation key per custom production (eg EPEL), that is (usually) set on hostgroup level and also just ERB templated into the subscription-manager command. Those keys assign the subscription for the corresponding product and activate the repositories.

This is quite a mess and somewhat of a management-overhead nightmare, but it gives us the most granular control on the CV side over what we need. Products basically are always a mess and it’s just “pic your poison” and roll with what makes the most sense to you.

Depending on your needs, the size of your setup and the use-cases you have, a lot of setups can be considered and you need to choose the options that give you everything you need without adding unnecessary overhead.

Thanks very much for your thoughts on this!


I would always recommend to start defining a naming convention for every foreman item, this could cause some headaches at first and seems unnecesary which for small deployments could be true, but for mid/large organizations this should be a must.

You will see how easy you can write your kicstart/erb/yaml/shells scripts and the speed of deployment using this approach, just to mention some of its advantages using this approach.