Logically Building & Managing Content Views

Support
1

Hi all, I’m writing in because I think I need just a little help with fully wrapping my head around content views in Foreman. I’ve read some documentation, which I don’t blame for my lack of understanding, I am just not putting it all together for some reason in my brain!

So let me lay out an example and then ask my questions.

Host Types
I’m basically managing two types of systems with Foreman:

  • CentOS 8 servers
  • CentOS 8 kiosks

Lifecycle Environment
And my lifecycle environment looks like so:

  • Library > DEV > QA > PROD

Products
Here are the products I have created for said systems:

  • CentOS8 - This product contains all of the CentOS repositories.
  • Extras - This contains repositories that my team will use to put custom RPMs in. It contains three repositories:
    • Servers - Extra packages for our servers.
    • Kiosks - Extra packages for our kiosks.
    • Application - Contains custom RPMs that deliver our in-house application and components.

Content Views
Now, I build several content views using my products:

  • CentOS 8 for x86_64 - This content view contains:
    • The “CentOS 8” product
      • All of its repositories.
  • Server Extras - This content view contains:
    • The “Extras” product.
      • The “Servers” repository only.
  • Kiosk Extras - This content view contains:
    • The “Extras” product.
      • The “Kiosk” repository only.
  • Application - This content view contains:
    • The “Extras” product.
      • The “Application” repository only.

Composite Content Views
Now that I have the main content views created, I create two types of composite content views:

  • Servers - Contains the following content views:
    • CentOS 8 for x86_64
    • Server Extras
    • Application
  • Kiosks - Contains the following content views:
    • CentOS 8 for x86_64
    • Kiosk Extras

Overview
So that is how I am logically (or non-logically) organizing this stuff. I can think of a few other ways to do it, but my brain is hurting trying to figure out what makes the most sense, and what won’t be hell to manage.

My idea at least is that I simply subscribe “server” type hosts to the “Servers” composite content view and “kiosk” type hosts to the “Kiosks” composite content view, and those systems can get what they need, while the lesser content views, products, and repositories underneath are logically separated.

I would then have some lab systems subscribed to the “DEV” environment, some to the “QA” environment and production systems obviously to the “PROD” environment.

So now that I’ve explained my environment, my first question is…
Does the above make sense in regards to how I’ve logically separated things? Do you foresee any difficulties I may encounter by doing it like this? Maybe I should opt for something a little more simple?

So lets say I do go forward with everything setup like the above, here is a scenario I wonder about…

Scenarios
One scenario I’d like to walk through is the below. I have some questions throughout the scenario and if anyone can offer advice on them, it would be much appreciated.

Lets say I build a custom package that delivers something I need on my kiosks. I’d imagine the process would look like so:

  1. RPM is built.
  2. Via hammer, API or GUI I upload the RPM into the “Kiosk” repository in the “Extras” product.
    • So at this point, my package is in the “Library” environment, correct?
  3. Now I need to get my package into the “DEV” environment so I can install it on my development systems to perform my own unit testing. Here is where I get confused. Do I now go to the lesser “Kiosk Extras” content view, make a new version and promote it to “DEV” or do I go to the composite content view “Kiosks” and promote that to “DEV”? Or do I basically do both?
  4. I’d imagine I now promote my “Kiosk” composite content view version to “QA” and finally “PROD”.

Conclusion
I think I dumped enough in one single post for now! Apologies for the book. If anyone found the time to read through this and has any answers or advice for me, I would be very appreciative.

Thank you!

1 Like
2

Yes. At the moment it’s kind of weird if you want different lifecycle states for different CVs in a CCV, even though that seems like a logical approach. Right now, you need to promote the CV you have assigned to your host. If it’s the CCV you need to promote the CCV. It’s always the whole CCV consisting of specific version numbers of the CVs, as you can only assign a single CV/CCV to a host.

So what you cannot easily do at this time is to take your two CVs CentOS 8 and Kiosk and let’s say have a CCV for DEV consisting of the DEV Kiosk CV and the PROD CentOS 8 CV (because you don’t want to do CentOS 8 testing on your Kiosks). You can specifiy the CV version number for your CCV but then you have to manually adjust it if you move forward, e.g. if there is a new CentOS 8 PROD CV you want to integrate into your Kiosks.

I have opened am issue for Lifecycle based CCVs which would more suit my needs, where you could configure a specific environment version to go into a CCV.

See Feature #30223: Lifecyle based composite content views - Katello - Foreman However, it’s on backlog.

So to answer your questions:

Re 2. Yes, it’s in the Library first.

Re 3. You have to publish your Kiosk Extras CV and then the Kiosks CCV (unless you have configure the CCV to auto-publish). Then the Kiosk Extras CV and the Kiosks CCV are in the Library, too. Now, you have to promote the Kiosks CCV to DEV to get it to the hosts which use the Kiosks CCV. The lifecycle environment of the Kiosk Extras CV is irrelevant here.

Re 4. Correct. You would take the Kiosk CCV to QA and PROD.

But as you can see, if you have new CentOS 8 Updates you want to integrate, it’s the exact same process. That may or may not be what you expect and need.

2 Likes
3

Thank you so much for taking the time to reading my questions and answering them. This is a fantastic community.

1 Like