Katello on Existing Foreman Status

Hi all,

Some of us are working on the design for how one might take Katello and install
it onto an existing Foreman. We identified a number of areas that we have to
account for.

This is the current state of our thinking, and would appreciate some feedback
on the items below.


··· ---------- Installing Katello should mean "foreman-installer --enable-katello", or similar, through the use of scenarios.

Original discussion:

The idea here is that Kafo supports “scenarios.” The full feature still needs
to be fleshed out, but the way I see it is with a number of scenarios
integrated into the single foreman-installer you could combine multiple
settings under a single option (using Salt for a simpler example):

foreman-installer --enable-salt

instead of some hypothetical much longer command like:

foreman-installer --enable-foreman-plugin-salt --enable-foreman-proxy-plugin-salt
–enable-saltmaster --enable-salt-sudo

This would adress Feature #9308: Add hooks to enable multiple plugin parameters for plugins - Installer - Foreman, but needs
to be a little more complicated.

‘foreman-installer --enable-katello’ would be able to change the default
values for a number of foreman default values (enable taxonomies, etc),
as well as pulling in katello modules and all those additional params.
So you can easily convert the existing Foreman-only answer file to have
all the right settings for Katello.

This raises the problem - what if two scenarios want to change the same
setting to conflicting values? Other issues come up here as well - we
really need to support running the installer between versions.

It’s required for Katello to ensure all our moving parts get the new
configurations after an upgrade. Eric has done some work on this -
doing a diff of an answer file between two versions should let us create
some kind of migration, but this issue definitely needs some more
thought and design behind it. We’re quite lucky for 2.0->2.1->2.2 that
we couldn’t pull in any of the foreman module changes. That changes in

We’ll also need a way to migrate existing katello users to the scenario-based

It looks like the core team has resurrected this topic as well. Should we do
this as a separate feature team as a pre-req for Katello on Existing Foreman
(KoeF)? Maybe we should get together and try to figure out what it will take to
do this with some of the people who are working on Kafo?


Certificates is a major difference between Katello and Foreman, and has
certainly caused issues (see: recent openscap client confusion with Katello vs.
Foreman). This is something that needs to be resolved for a Katello
installation on an existing Foreman, too.

We’re still experimenting, but have some early thoughts about this:

  • an existing Puppet CA could become the root CA for the katello CA

  • abandon katello-cert-tool in favor of using puppet-openssl

  • capsule-certs-generate is modified for foreman use too


We’d like to move away from the concept of capsules upstream and leave this to
be terminology used by the Satellite product. At the end of the day, Capsules
are foreman proxy’s with Katello features.

In order to do this, we need scenario support to enable the multitudes of
options a Katello content foreman-proxy needs, and we also need an equivalent
to capsule-certs-generate to make installing a new foreman-proxy easier:
bundled certs and oAuth bits.

The current foreman method of leaving it up to the user to basically do all
this to build an independent Foreman proxy just won’t work with Katello, and I
see this making things much simpler for Foreman users too.


If we have the above, we just need Katello to support synchronizing front-end
objects with the backends. Currently we do this when the object is created
(users, organizations, etc), but we’ll need to change this around to be able to
do it during any db:seed (?). Once this and the above items are addressed, it
should be possible to install Katello on an existing Foreman.

It’s certainly a lot of work, especially the installer and certificates parts.

There’s a few optional things we’re looking at as well -

  • Support MySQL? How important is this to the community?

    • Some Katello migrations are incompatible (although the first
      incompatible one is from mid-2014, so it’s not that bad of a situation)
    • Candlepin supports MySQL (theoretically)
  • Removal of elasticsearch

    • We decided to move this to the core team, unless anyone objects. It’s not
      strictly tied to Katello on Existing Foreman, just a nice to have. The inital
      KoeF design will probably still add elasticsearch to the foreman
      box until its completely removed

Best Regards,

Stephen Benjamin
Red Hat Engineering