my plan is to add support for version locking to Foreman and I’d like to know your suggestions and find possible caveats I missed during the preparation.
When yum update is run on installed Foreman/Katello/Satellite system it can upgrade also
Foreman related packages which can lead to the instance being half-updated with
run-time failures. Installer then needs to be run manually to finish the upgrade.
Lock Foreman related package versions to prevent updating those.
Yum has a plugin
yum-plugin-versionlock that allows user to protect packages from being updated.
The proposal is to extend foreman-installer (Kafo) to use the yum plugin to protect the packages
after installation finishes. It is done by simple listing the packages and their versions in
/etc/yum/pluginconf.d/versionlock.list. Installer then would need a new option or subcommand to unlock the packages later before Foreman upgrade.
The most problematic part is to find the packages to lock. The first candidates are:
- foreman* (foreman, foreman-plugins, foreman-rails)
- katello* (katello, katello-client)
- satellite* (satellite, satellite-capsule, satellite-tools)
Are there any others (pulp, candlepin)?
We should probably keep the list configurable in scenario config.
We need to cover the following scenarios:
foreman-installer --scenario <scenario>
- perform installation as usual
- after installation write list of actual Foreman related packages to the version lock config
- foreman related packages are locked and skipped
Upgrade of installed Foreman that has packages locked
- install new repos
- removes the locks
- locks the updated packages again
Upgrade of existing Foreman with no locking
- install new repos
- updated installer locks the updated packages
Is it possible to disable version locking?
Information if locking is enabled for the installer scenario is writen in scenario
config file and can be updated manually or by installer switch.
What to do when version locking is already used at the machine?
It is possible to add our own entries to the existing versionlock file. To be able to
distinguish our packages we will write a copy to
Does it make sense to lock repos with collections we do not provide?
It should be safe to keep RH SCL unlocked. Needs to be confirmed
Can this work on Debian?
Debian has similar concepts implemented via
apt-mark hold/unholdor apt blacklist feature
More info needed.
How it will work with foreman-maintain driven upgrades?
The only change for foreman-maintain should be to call
- [RFE] Have a warning in Satellite 6.x that a satellite upgrade is required if a yum update only was done https://bugzilla.redhat.com/show_bug.cgi?id=1459358
- [RFE] find out if foreman-installer --upgrade was run after yum update https://bugzilla.redhat.com/show_bug.cgi?id=1316246
- [RFE] Implement a yum version lock type of protections against upgrades https://bugzilla.redhat.com/show_bug.cgi?id=1512600