Deprecation plans for Foreman on EL7, Debian 10 and Ubuntu 18.04

[ehelms]

There is a recent community demo that shows how to use Leapp to perform this upgrade:

Foreman Community Demo #110

Official documentation is in process along with a blog post.

[evgeni]

@jnana

Is there a documented in-place upgrade path for RHEL7? The leapp method here mentions it won’t work on RHEL7.

If not, is there a tested and working way to export the data (without pulp/packages) from Foreman/Katello installed on RHEL7 to a fresh install on RHEL8 or even RHEL9? I have the same concerns as post #18 above.

I’ve updated https://github.com/theforeman/foreman-documentation/pull/1248 to have RHEL steps too now.

And no, you can’t export data w/o packages.

[jnana]

@evgeni

I’ve updated Created module for RHEL 7 to RHEL 8 upgrade by bangelic · Pull Request #1248 · theforeman/foreman-documentation · GitHub to have RHEL steps too now.

Thanks for this, I’ll watch it and plan to test the upgrade once there is more complete documentation around it.

@evgeni

And no, you can’t export data w/o packages.

Would this be worth supporting in the future? From the sysadmin side having brought a production system from Foreman 2.1 to 3.1 with the usual issues during almost every y-stream upgrade, it would be a boon to be able to quickly throw a streamlined backup onto a fresh install and let it sync the packages after.

[evgeni]

@jnana

Would this be worth supporting in the future? From the sysadmin side having brought a production system from Foreman 2.1 to 3.1 with the usual issues during almost every y-stream upgrade, it would be a boon to be able to quickly throw a streamlined backup onto a fresh install and let it sync the packages after.

Given most repos don’t serve historical packages, you wouldn’t be able to sync and get a broken setup.
(Or one that absolutely doesn’t match the one you “backed up”)

[jnana]

@evgeni

Given most repos don’t serve historical packages, you wouldn’t be able to sync and get a broken setup.
(Or one that absolutely doesn’t match the one you “backed up”)

Yes, that would definitely be an issue for installs with the need to keep older versions. However, more options and robustness in general for backup surrounding these kind of cases, such as whether to export only packages that are marked such or no longer exist in the source repo, would really help. I can’t speak to the feasibility of these options, but if they existed now it would make upgrade testing and planning much quicker and easier for organizations with larger setups.

[gvde]

@evgeni

Given most repos don’t serve historical packages, you wouldn’t be able to sync and get a broken setup.
(Or one that absolutely doesn’t match the one you “backed up”)

Why is it a broken setup then? Technically, it should simply clean it up and fine.

And if I don’t use backup but set up a complete new server with the foreman ansible module it won’t serve historical packages either.

And either way: why must the backup include the complete pulp directory? For me, it would be much more efficient, if the backup only included everything else needed and I take care of getting a complete copy of the pulp directory to the target server (which would be pretty easy as it’s on a separate virtual disk in our virtual environment…) That would safe me a lot of time and terabytes of data copied around by the backup/restore process…

[evgeni]

@gvde

Why is it a broken setup then? Technically, it should simply clean it up and fine.

But it won’t. Pulp has its state in the DB and there it says “the file is on disk” whereas there is no file on disk.
Is that ideal behavior? Probably not. But it’s what we have today.

@gvde

And if I don’t use backup but set up a complete new server with the foreman ansible module it won’t serve historical packages either.

Sure, but then pulp won’t think it has all the data.

@gvde

And either way: why must the backup include the complete pulp directory? For me, it would be much more efficient, if the backup only included everything else needed and I take care of getting a complete copy of the pulp directory to the target server (which would be pretty easy as it’s on a separate virtual disk in our virtual environment…) That would safe me a lot of time and terabytes of data copied around by the backup/restore process…

You don’t have to include pulp data in the backup, you can skip it and create the copy by some other means (rsync, whatever) and the restore will restore fine (minus the fact that you now have to provide the pulp data yourself). Just make sure whatever is on disk and in the DB matches.

[jnana]

@evgeni

You don’t have to include pulp data in the backup, you can skip it and create the copy by some other means (rsync, whatever) and the restore will restore fine (minus the fact that you now have to provide the pulp data yourself). Just make sure whatever is on disk and in the DB matches.

Does this mean the following procedure (high-level) is possible?

1. We take a backup of a Foreman 3.1 + Katello 4.3 install on EL7 by running “foreman-maintain backup offline --skip-pulp-content”.
2. We set up a fresh install of Foreman 3.1 + Katello 4.3 on EL8/9, keeping the same hostname/IP.
3. We copy the /var/lib/pulp directory from the EL7 system to the EL8/9 system.
4. We restore the foreman-maintain backup from the EL7 system to the EL8/9 system. After the restore completes, we should have the same functionality and host/repo/subscription/CV/etc data that we did on the previous install, and nothing needs to be changed on the clients provided we keep the same certificates. This includes RHEL clients and repos.
5. We can continue to upgrade Foreman+Katello on the EL8/9 system as normal.

Interested in hearing your perspective on if this approach will work.

[evgeni]

Yes, this should work.

This is also roughly how we document to clone a Satellite server (see Chapter 2. Cloning Satellite Server Red Hat Satellite 6.10 | Red Hat Customer Portal), which reminds me that I still wanted to finish up the work of making satellite clone also support plain Foreman and Katello setups.

[ehelms]

At this time we have dropped EL7 from our nightly testing pipelines. We are no longer generating EL7 nightly repositories nor testing installations or upgrade against EL7. We are continuing to work in this area to remove the nightly release repositories on EL7, as well as cleanup packaging to stop building all but client packages on EL7. Forklift has also been updated to drop EL7 as a nightly and development environment option.

Developers – this means that if you are using an EL7 based development environment, it is now out of date and will not be update-able - Please find time and move to an EL8 based setup. There is no in-place upgrade for development environments.

[heyitsgary]

Is there any ETA or more information around when a clone tool will be available for Foreman?

[gvde]

I don’t see any notes on deprecations in the Foreman 3.3 and Katello 4.5 Release Notes

But that is now the last version with EL7 support? 3.4 won’t?

[ekohl]

It looks like the entire Foreman release notes weren’t added. Normally speaking they should have been copied. Foreman 3.3.0(GA) release process shows an unchecked checkbox but worse, some steps are missing. Looks like Add steps to update the index, versions of docs.theforeman.org on GA · theforeman/tool_belt@9b9e704 · GitHub was not present in the checkout when the process was applied.

[gvde]

O.K. But beyond the reason why release notes are missing: regarding my question? Which version is the last supporting EL7?

[ekohl]

While adding the docs I noticed it was also missing from the other docs:
https://github.com/theforeman/theforeman.org/pull/2003
Then this also adds them to the new docs site:
https://github.com/theforeman/foreman-documentation/pull/1436

Thanks for bringing this up because it is quite crucial information for users.

And to answer the question directly: Foreman 3.4 will drop EL7 and Debian 10.

[rgp]

Thanks for this answer. Is CentOS8 (EOL) and RHEL8 the only supported EL8? What about 8stream, rocky, alma? What EL8 packages build against?

[ekohl]

We currently build our RPMs against CentOS Stream (https://github.com/theforeman/foreman-infra/issues/1670 would change that to RHEL).

Then we have testing pipelines which run on CentOS Stream and AlmaLinux (so we at least test with something that’s at most as new as RHEL). Note that these do not stress all aspects - it mostly just verifies a basic installation can be done is at least on a high level functional. From there we assume RHEL 8 and Rocky work.

Grub is one area I know there may be some issues since it uses the vendor’s name in the path:

theforeman/puppet-foreman_proxy/blob/7343bb559cf7b0220d631f763a06ee696a2f72e3/manifests/tftp/netboot.pp#L31-L34

So this may break Oracle or any other RHEL rebuilds you may use. We also don’t document installation instructions.

So there is some level of best effort support for Rocky. Patches are welcome

[lumarel]

I have been smooth sailing on Rocky Linux 8 close to a year now, didn’t encounter any issues specific to it
Yeah Alma is used in the pipelines (which could indicate something, but I don’t really think so, it was implemented but still don’t see a preference), but I don’t really think that proves any downsides for Rocky, Foreman and Katello work very very well on both (well all 4 mentioned) platforms!

[ekohl]

This has been done and is executed. Marking as resolved.