Hello all,
I’m new to the community and to Foreman, so I apologize if this is a newb question.
In general, is it better to create relatively complex composite content views (at least, they seem to be complex to me), or to use multiple activation keys when subscribing clients to foreman? Or some combination of the two approaches?
What criteria can I use to determine which is the most appropriate path?
Thanks,
Drew
Hello and welcome Drew!
I’ll move your question to the support category where hopefully someone from @katello team can provide you with guidance 
Hi Drew,
as so often, the answer is “it depends (on your organization)” 
If you have just one type of servers (say webservers) and one type of OS (say Centos7) you can easily get away with just one content view (CV) and one activation key (AK), but I bet it’s not that simple, so let’s see what you can do.
A CV is a representation of content that belongs together, especially you cannot (easily) update parts of a CV without updating all content. So if you put two repositories in a CV, each publish will update packages from both repos. This is great if the repos belong together, like base and extras of Centos, but will make headache if you combine centos and epel, or your monitoring agent. Mostly due to the fact that the components then have different update intervals. So my personal guidance is usually "use one CV per product (centos) which can span multiple repos (base, updates, extras).
As having just an OS is kinda useless, you then usually end up doing composite content views (CCV) that combine the OS with an application, e.g. you take the centos CV plus foreman CV. As those products have completely different update cycles, you can update the CVs as the products update and then present this to your consumers in the CCV.
Now AKs allow you to “configure” what consumers can see. They provide subscriptions, as without an subscription a consumer wobt be allowed to access a product. And they provide a list of enabled by default products. So you could have a key that allows the consumer to acces centos and epel, but epel is disabled by default while centos is enabled. As your CCVs provide multiple products, you can either configure all of them in one AK or use multiple AKs to “compose” again. Personally I find using multiple AKs easier to manage in the long turn, as you end up having less AKs, but it can be confusing at first how they work together.
I hope the above makes sense and please ask if you need more input, preferably with some examples what content you want to serve.
Hey Drew,
I am assuming you want to have a granular way to apply RH subscriptions to host.
Composite content views give you more control on the content that is available to the host. It also helps in the curation process giving you ability to filter out stuff you don’t want.
That being said, with the multiple activation key approach you can also get granular with respect to the subscriptions attached. However all the activation keys you specify should belong to the same Content View/Lifecycle environment.
So if I understand correctly, there is no single solution to this situation (sorry – I thought I was just overlooking something).
If I have multiple content views, let’s say I have:
All of those have different update cycles, so I combine them in a single composite content view, associated with a single activation key.
If I have systems that don’t need access to epel or docker, I then need to create a second composite content view (with a second activation key) with the following:
And if I need to filter the docker repository to only provide access to docker-ce-1803, while other hosts need access to docker-ce-1809, then that would be 2 more composite content views, each with an associated activation key.
Is that right?
Sorry – just trying to figure out how to represent the complexity within foreman/katello.
Thanks!
Drew
Hi,
I will take a shot at helping you out here.
The whole Repo/CV/etc topic is probably the most complicated part about getting started with Katello. If you want to understand the concepts behind all of that, I did a somewhat extensive writeup about this a while ago in this thread. The post is a little dated, but the core principles stayed the same.
For your last example, I would suggest a setup like this:
Use 4 CVs:
Then, build a composite content view with those 4. Alongside, I would use one activation key per content view (or, in the case of docker where there might be different versions used on different systems in parallel, one per repo of that content view).
Since a System with an OS does not work, I would use the CentOS7 key to assign the CCV and lifecycle environment. Please not that using more than one key with these options on the same host (system you want to install) will result in unexpected behavior, so don’t overdo this. If you want the systems to be in different lifecycle environments, I would suggest duplication the CentOS7 key per environment.
The other keys should just set the repositories you want to enabled.
This way, you will have a little more overhead when updating your repos (because you always need to update the composite content view, too) but you also get a lot more flexibility and reusability.
Regards
Thanks areyus! That’s the setup I wound up using so far. It just seemed non-intuitive, so I was curious if I was missing some guidance somewhere.
I also appreciate the link – that discussion helps provide more context around this topic.