TFM 3.5+ upgarde planning + Alma (rocky/rhel) 9

I appologized if this has been asked/answered but the best result I found was the rfc post listed below.

We are currently running TFM 3.3.0 on CentOS 7. We have no plans to deploy Alma/Rocky/CentOS 8 as an OS which keeps us on the 3.3.x branch. We have started baselining Alma 9 but it doesn’t look like there are published packages yet (release notes + yum repo). Is this expected to change in 3.5? ( Foreman :: Manual + RFC - Enterprise Linux 8 and 9 Support ) Given that 3.5 is already in RC I completely understand it not being included as the scope could be quite large.

Given upgrades typically say to install from one version to the next what would kind of paths might be available once EL 9 support exists? Do we need to start considering a one off for our TFM install to step through the versions on the way to the EL 9 supported version? Can we just do a database backup + saved installer profile and restore on EL 9? I do realize this is not exactly a straight forward question and there are a lot of variables but appreciate any insights folks can share.

Currently running:
TFM 3.3.0

  • puppet plugin
  • hooks
  • discovery
  • tasks
  • remote_execution
  • setup
  • templates

I can’t add much detail here, but having been in the same situation, we selected Rocky 8 as the current stable branch and the backup/restore worked pretty well, except for the keystore password overrides. There is a thread out there which shows a possible solution, but I am not sure you will even hit that issue. If you do, I’m happy to pull that for you.

We’re far from being able to run on EL9 yet (see details in Path to Ruby 3.0, 3.1, EL9 and Ubuntu 22.04) and don’t have a date until when we can commit to be able to change that. So your choices are either getting a system with EL8 and run Foreman there or stick to the 3.3 branch which won’t get any updates once 3.5 is released.

Thank you for that thread, it’s hugely helpful as far as timelines and scope of work on the foreman side.

As a follow up, are there any thought on ways to support skipping versions or restoring from an earlier version’s backup when updating for those that do/did not plan to deploy CentOS/Alma/Rocky 8? This is probably the crux of our concern at the moment. Since we are not currently planning to deploy an 8.x OS I don’t see a clear upgrade path where skipping the 8.x OS is possible based on past upgrade release notes.

You’re gonna love the answer, but: it depends :wink:

Usually, I would expect updates skipping a few versions to work fine, but:

  • We do not test this, so if it doesn’t work, it’s not really a bug
  • Restoring a backup of version X on version Y might work (or might not), and this again wouldn’t be a bug if that doesn’t work
  • If things don’t go as smoothly as wished, we might not have the time to dig deep into your specific problem
  • Your chances are higher if you don’t use Katello (it wasn’t on your plugin list, but still good to call out)

Thanks! That’s about what I expected – 42.

Given our dependencies on this we will likely evaluate a one-off host to 8.x to ensure a clean path forward.