Others may have heard me talk about this, but it’s time to write a real RFC about this.
Goal
Have a single git repository with all our installer scenario’s. We can separate this in packaging, to remove the katello scenario on Debian/Ubuntu for example.
Benefit
Currently there’s a lot of duplication between the two repositories. Most checks are duplicated, migrations are applied in both places, hooks have overlap.
The katello-installer build is also complicated because it layers on top of foreman-installer. This is fragile and has broken a few times. By delivering a single installer with one big modules directory means our kafo module caches are always in sync.
It’s also easier to know exactly what is installed since you only need to check one package.
Downsides
We will ship more modules. Especially on Debian this means more disk space used. This may be a few MB so it’s not that bad.
There can also be side effects. Currently there’s a bug that means puppet-service_wait breaks the systemd fact. This means we can’t apply systemd limits in katello-installer. It’s likely we’ll pull this bug into foreman-installer as well. This should motivate us to fix bugs earlier.
Approach
My initial approach was to slowly merge all the hooks and checks into foreman-installer until we could move over the configs and modules as well. I presented this at Cfgmgmtcamp earlier this year.
This week I decided to go the other way: start with moving everything over and then within the repository we can work to merge the hooks.
Proof of Concept
Today I started on a proof of concept. The result is that it builds, creates an RPM but I haven’t had time to test this on an actual system yet.
Generally I think this is a good plan all around and lets us focus on one code base. The biggest downside to me is that this now ties the installation bits of Katello to the foreman-installer release cycle. This means a few things for both Katello and Foreman:
There would be no Katello tests gating the release of new installer bits which could potentially break nightlies
Foreman installer release would have to be mindful and potentially gated on breaking Katello
Katello would need to ensure a tight release cycle with Foreman. This can be lessened by the Puppetfile.lock on release branches locking dependencies to reduce churn
One option to help with release is that we merge the code bits, but we spit out a sub-package that lives in the Katello repository. This would keep the code base as one, but allow splitting the bits into repositories that could continue gating based on testing.
There is absolutely a tighter coupling to the foreman release cycle. One option I considered is letting go of the coupling between the various foreman packages. Currently we release foreman{,-{proxy,selinux,installer}} all at once even if nothing changes in them. This means that if we need to do an installer release for katello, it also implies 3 other releases. If we decide to let go of the coupling, then we’re free to do async releases. This has much bigger implications than just an installer merge so consider this carefully.
This is correct, but overall I think we’re very careful with compatibility. In Foreman modules we try to maintain a policy of supporting the current release + one older release (if needed via parameters). This has worked well and requires much less gating.
We already have this partially for other plugins, but they’re not nearly as big. I do see it as a good thing to consider various aspects as first class citizens. I’d love a standalone pulp scenario for example. It could even follow the upstream releases and ignore katello coupling.
We already do this, correct?
What would live in this subpackage? The answers, migrations and scenarios or also the puppet modules?
We try but don’t always succeed. For example, for 1.18 Katello is going to be 1-2 weeks behind in branching.
At a minimum the config/ bits such as answers, migrations, scenario. The modules and hooks might as well live in the sub-package as well since they have no impact on Foreman scenarios.
My hope is, that the change would actually make this easier for next releases. It should motivate everyone to keep nightlies stable, therefore Katello should be ready for release in any point in time.
With a slight delay I should update here that I’ve been working hard this week to complete this in time for 1.21 while allowing still some time to let it mature in nightly. The current status is that @ehelms and I have tested it and intend to merge it today.
The linked PRs do capture much more of the intermediate design discussion. The short summary:
We’ll have one git repository: foreman-installer.git
All installer builds will ship all required Puppet modules
Debian builds will not contain the Katello scenarios and their required files
RPMs
There’ll be single source RPM
All Katello related scenarios live in the foreman-installer-katello subpackage.
The old katello-installer-base package will be obsoleted by foreman-installer-katello.
Any tooling that relies on katello-installer-base should update.
