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.
Problem
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.
Proposal
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:
Are there any others (pulp, candlepin)?
We should probably keep the list configurable in scenario config.
We need to cover the following scenarios:
Fresh install
foreman-installer --scenario <scenario>
perform installation as usual
after installation write list of actual Foreman related packages to the version lock config
System update
yum update
foreman related packages are locked and skipped
Upgrade of installed Foreman that has packages locked
install new repos
foreman-installer --unlock
removes the locks
yum update
foreman-installer
locks the updated packages again
Upgrade of existing Foreman with no locking
install new repos
yum update
foreman-installer
updated installer locks the updated packages
FAQ
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 /var/lib/foreman-installer/versionlock.list
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
@iNecas, that is a good idea. I tried to get to the information and the only way that worked for me on upstream installation and instance using subscription manager was repoquery -a --qf='%{envra} %{repo.baseurl}'
If we filter the output by the url we have what we need. Is that what you.ve meant?
I guess we can get the url to filter by from well known pacakge e.g. foreman-installer.
Does it make sense?
If the foreman/katello repos were set to enabled=0 in the repo file in /etc/yum.repos.d and foreman-maintain enabled them via yum update --enablerepo=<repos>, would that work also?
One could make the argument that having this capability in foreman-installer itself protects you in the event that the user updates the packages without using foreman-maintain. (i.e. at this time, the installer might be the only place where we can ‘interdict’ the users behavior).
You mean as an alternative to version locking? It may work, however I believe the installer may want to install some dependences and repoquery functionality will be limited (not sure if we are using it in any tools).
Also installing anything (tools, plugins) from our repos will require to enable the repos manually. I guess the workflow will have to be very similar as with versionlock. It would be quicker and easier to implement but prevent us to lock just the installed packages (vs. locking whole repo)
Sure, as @SideAngleSide pointed out, foreman-maintain is not used always. Certain scenarios - fresh install, Foreman upgrade, proxy upgrade, Debian systems - are not supported in foreman-maintain yet.
It could be possible to implement it as a separate script in foreman-maintain repo maybe even as a part of foreman-maintain itself, and be called from both the installer and the foreman-maintain upgrade. The installer would lock files at the end, foreman-maintain upgrade unlock could unlock for scenarios where upgrade is not supported in foreman-maintain yet. I’ll have to check how the packaging deps are set. Would it make better sense?
While I understand the reasoning behind this suggestion, my one concern regards ease-of-use - Foreman is already not simple to install or upgrade correctly. This adds another manual step to the process, that may also fail or have other issues in it. It also adds yet another option to the installer that already has IMHO too many options.
To me, I think it would make more sense doing it only in foreman-maintain. if you use one tool that is supposed to wrap the install and upgrade process’s multiple steps, this feels like a good way of ensuring it isn’t done outside of the tool, but if you don’t use that tool, than you shouldn’t need extra steps in an already complex process (so complex that we wrote another tool to simplify it!).
I would agree with this if foreman-maintain is always wrapping the installer. But we are not there yet. There are scenarios which foreman-maintain does not support yet and e.g. for the clean install we are not anywhere near.
Would it be acceptable to make locking as separate as possible to allow easy transfer to foreman-maintain when it is ready for the job? It could consist of:
extending scenario with attribute lock_packages to allow opt out version locking (adding --lock-packages true/false to the installer)
version lock/unlock being separate script in foreman-maintain
installer calling the script in post install hook according to lock_packages setting
forman-maintain driving the upgrades without manual steps
foreman-maintain being the tool for manual unlock if necessary
It would also allow us to set the locking as opt-out for some scenarios and opt-in for others. Also version locking wold be smooth in upgrades via foreman-maintain and possible without it (with extra manual step).
Hi, from a support perspective I would also be in favor to implement it in foreman-installer.
The most common case we have is that users who have a fresh install and/or never used foreman-maintain are prone to run arbitrary yum update.
If the solution is implemented in foreman-maintain, we would not address the main root cause, imho. I believe the only way to make sure we have version locking right from the beginning would be via the installer itself.
