Version locking of Foreman packages

upgrade
installer
rfc
maintain

#1

Hello all,

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:

Upstream:

  • foreman* (foreman, foreman-plugins, foreman-rails)
  • katello* (katello, katello-client)

Downstream:

  • 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:

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

  • Can this work on Debian?

    Debian has similar concepts implemented via apt-mark hold/unhold or apt blacklist feature
    https://www.tecmint.com/disable-lock-blacklist-package-updates-ubuntu-debian-apt/.
    More info needed.

  • How it will work with foreman-maintain driven upgrades?

    The only change for foreman-maintain should be to call foreman-installer --unlock before
    it runs yum update.

Related issues

Thanks,
Martin


#2

Makes sense to me.

Would it be possible to compile the list of packages based on it their sources: lets say all packages coming from yum.theforeman.org?


#3

@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?


#4

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?


#5

Could you expand on any considerations you made as to why we should put this in the installer instead of foreman-maintain?


#6

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


#7

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)


#8

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?


#9

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!).


#10

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