Yoram's Notes

Introducing Ballista Some time ago I created a few tools and a library to interface with the Satellite 6 installation at a client and  made   some posts  about that. While these tools got some use, we found that what we really wanted was a tool that was easily extended and consistent in its use to manipulate our Satellite 6/Katello installations. So, together with my colleague Joey Loman  I set out to create a comprehensive tool and provide an infrastructure for future functionality and supplement the existing hammer-cli interface. You can check it out at   https://github.com/RedHatSatellite/ballista

The problem When using the whole concept of Content Views in Satellite 6 the way it is intended, you can end up with a lot of unused versions; every time a new version is promoted to all your environment, you end up with an unused one. When using a lot of content views and especially when using Composite Content Views that end up with a new version every time one of their components get updated, you end up spending a lot of time removing the via the gui. The solution (well, a  solution anyway) While you can clean them up using hammer in a loop, you need to make sure you only remove versions that are not currently used by environments. Since I already made a python library for various tasks, it was trivial to add a small script that removes every version of a content view that is not in use. We use this at my current client and it saves a lot of time, maybe someone else can find a use case for it too:) You can find it at  https://github.com/yhekma/satellite6_tools ...

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 con...