Recursively update Composite Content Views in Satellite 6/Katello

The basic idea

Satellite 6 (and Katello for that matter) have a new way of dealing with content, whether it being puppet modules, rpm's or docker images. Below I will focus on rpm's, which I think will be the use case for most people.

A content view can contain one or more rpm repository's at a specific point in time but can consist of multiple versions. So let's say I create a content view named RHEL7_BASE on Monday containing 2 repositories I just synced: rhel7_server and rhel7_epel. Version 1 of that content view points to the packages as they are on that Monday. Now the next Friday I do a sync of my repositories so I get the latest versions and patches and whatnot, but note that version 1 of my RHEL7_BASE content view is unchanged, and any servers that are using this version will not have access to the new packages. In order to make these new packages available, I need to publish a new version of the view and promote this version to the environment that contains the server.

The way it works and is intended (as I understand) is that given a number of environments (say Dev, Test, Acceptance and Production) one version of a content view is pinned to these environments. This can be the same version, in which case all of your DTAP environments will be at the same patch-level but I think it will be more common to have Production lag behind Acceptance for instance.

Complications

Now, given the existence of content views as described above, there is a catch: a server can only access 1 and only 1 content view at a time. This may not seem too problematic, until you want to compartmentalize you content. Let's say you have a RHEL7_BASE content view and an ORACLE_11g content view. You want your server to have access to both repository's/content views and be able to patch both oracle and redhat (but not necessarily at the same time), but since we can only get access to the content of 1 view, this is simply not possible. One solution might be to create one big content view containing Oracle as well as RHEL7 content, but this gets old fast when dealing with a lot of applications.

Composite Content Views to the rescue

In order to tackle this problem, one can use Composite Content Views. These are simply content views that contain other content views, thereby making it possible for servers to access the content of multiple views. These composite content views themselves have versions, just like normal content views, but instead of pinning repository's at a specific point in time they pin the versions of the content views they contain. So version 10 of my COMPOSITE_ORACLE, which I use in my Production environment,  contains RHEL7_BASE at version 6 and ORACLE_11g at version 23 while my Test environment uses version 11 of COMPOSITE_ORACLE which contains RHEL7_BASE at version 8 and ORACLE_11g at version 29.

If I then want to be sure that my Production environment contains the same RedHat patches as my Test environment, I publish a new version of COMPOSITE_ORACLE (version 11) which still contains version 23 of ORACLE_11g, but version 8 of RHEL7_BASE. This new version I will link to the Production environment.

Automation (and getting to the point)

Having said the above, please note that promoting content views can take a pretty long time. Also note that if you have a lot of composite views which contain the same base view (RHEL7_BASE would be included in a lot of composite views for instance), it can be a pain to figure out which composites are impacted by an update of a base view. So I made a python script that updates an arbitrary number of content views, looks up the composite views that use them and publishes new versions of them as wel pointing to the newest base views (note that these composite's do not get promoted so you can still decide which version gets deployed where).

I have published my code at https://github.com/yhekma/satellite6_tools