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

It’s that time again when we should talk about deprecation plans for distro support.

The benefit that’s true for all plans below is less work to support a distribution. Over time it becomes harder to support since you’re getting used to features present in newer distributions. Resources are finite so it’s best to spend them wisely.


This is probably the furthest away, but given the large deployment I think it makes sense to announce it very early.

Let’s start with some facts. RHEL 7’s lifecycle is documented on Red Hat’s product life cycles. It is currently in Maintenance support 2 (see Red Hat Enterprise Linux Life Cycle - Red Hat Customer Portal for details). This means no new features are introduced and it’s only security updates. This phase ends in 2024. CentOS 7 will also go EOL at the same time.

For Foreman we have built for EL 8 since Foreman 2.1, but there have been some feature gaps. Katello being the biggest, but that’s been resolved with Katello 4.0. That means we can start to recommend users moving over.

Then we should also consider that EL9 is on the horizon. It’s expected that CentOS Stream 9 should be on the mirror network in a matter of weeks (source). This brings us to some CI limitations. We don’t have enough resources to do our pipeline testing on all OSes. Dropping EL7 will free up those resources.

For that I’m proposing that we start announcing with Foreman 3.0 that we’re deprecating EL7 support. Actual removal can happen later. This isn’t based on a lot, but I’m thinking about 3.2 or 3.3.

Debian 10 (Buster)

The Debian release table is here:

Debian 11 (Bullseye) was released August 14th. We have not started support to run Foreman on it. This needs to be planned and executed. Once we have Debian 11 support, we can give users 1 or 2 releases to migrate over. That’s how we’ve always dealt with it. Debian 10 will go EOL in ~2022-08.

This means that if we’re optimistic we can deprecate Debian 10 support in Foreman 3.1 and drop it in 3.2 or 3.3, but this means we need to start working on it soon.

Ubuntu 18.04 (Bionic)

The release overview:

Ubuntu 20.04 support was added in Foreman 2.5. This means we can start to deprecate Ubuntu 18.04 support in Foreman 3.0. Actual removal can happen in 1 or 2 releases.

It should be noted that the actual EOL is in 2023, but this saves us resources. We are currently at capacity for Debian building/testing in our CI. Removal of Ubuntu 18.04 in Foreman 3.1 would free up capacity to build Debian 11.


So I’m proposing this:

Foreman version Notes
3.0 Deprecates EL7 and Ubuntu 18.04
3.1 Drops Ubuntu 18.04, adds Debian 11, deprecates Debian 10
3.3 Drops EL7 and Debian 10

If Debian 11 is not supported in 3.1, Debian 10 deprecation also moves to a next release and removal in 3.3 also moves.


:+1: on dropping old OSes.

I think the only concern I’d have (as a user) is that 3.0 deprecates Ubuntu 18.04 and 3.1 already drops it. Yes, 20.04 has been supported since 2.5, but we didn’t announce a deprecation and it feels wrong to do it in one release cycle then.

May I chip in here something from the user perspective on deprecating EL7: please leave more time. Much more time.

Two reasons:

  1. As Katello user, the upgrade from katello 3 to 4, i.e. migration to pulp3 was very painful. It took me a couple of months and several workaround, removing products, etc. to get my foreman/katello servers to katello 4 and there are still lots of issues open until it will be as good as it was with 3.18/pulp2. My Foreman servers and proxies all run on CentOS 7 at the moment. Several times, I have considered reinstalling from scratch but didn’t because of the amount of configuration involved to get everything as it was.

So what am saying: after months of painful migration attempts I would find it quite discerning if you tell me know, that in 9-12 months from now you have to move to EL8 (whatever way this may be and however well this migration may work).

Give users some time to get their systems to katello 4, mostly bug-free, and let them run the system smoothly without major administration for at least a year (so well into 2023). It’s just exhausting when it feels like you spend more time on getting something to run, keep it running, keep it updated, than to actually really use it and explore all the usage options you have.

  1. We actually haven’t really decided what comes after CentOS Linux 8. We are still evaluating and monitoring what’s out there and trying to figure out what’s the future for us. Alma, Rocky, CentOS Stream, Oracle Linux, even considering getting RHEL 8 licenses for some hosts until we are sure we have a new stable free platform we are confident about. It’s just my impression but I think this consolidation will go well into 2022 and I am worried I might have to pick an EL8 distro for my new foreman/katello because of the deprecation and may just regret it in the long run, because eventually we have focused on another distro.

So again, don’t tell people now they have to move to EL8 in these times of uncertainty. Give them at least 2022 to figure out which EL8 distro it’s going to be for them before deprecating EL7 support.

On a sidenote (or a third reason if you want): I generally really prefer products/software which in regard to distro support follow the EOL of the distro. I always now the distros and version and their EOL on my hosts. And for many of our servers we use the RHEL derivates to be able to keep them running for many years until EOL. We do this in particular so that we don’t necessarily have to go through every major version. We had quite a lot of hosts running CentOS 6 which we then replaced with CentOS 8 (before they have announced it’s EOL, too).

So my general expectation is that a product officially supports RHEL7/CentOS 7/EL7 would do so until EOL of EL7. That’s why we chose EL to begin with, because it’s supported for many years. If a product before that announces it’s deprecation of a still supported operating system, it’s quite disappointing and I would expect that quite a few people out there would rather keep their Foreman/Katello system running on EL7 with the latest support version then forcing a migration before time (if there are not too many bugs which make it hard to use Foreman/Katello properly).

And a final sidenote: there must be a well working migration process to move the existing server to a new installation on EL8. After the painful pulp migration I really don’t want to spend months again on a EL8 migration. Because otherwise, I’d start thinking if I had known that in the beginning before katello 4, it would have been much better to installation the whole thing from scratch instead of trying to migration first pulp and then to el8…


That’s why I wanted to start the discussion sooner rather than later.

I still think we should start deprecating EL7 in the release notes for every release starting 3.0, even if there is no exact end date yet. The same should be done in the installation instructions. This should achieve that new installations happen on EL8. It also makes admins aware that EL8 should become the preferred platform. Even if their Foreman isn’t migrated, they sometimes do install new Smart Proxies and they should be deployed on EL8.

As for the exact date, I can be persuaded that we should see where the dust settles after CentOS Linux 8 is EOL.

What I should have mentioned in the post is that we do have EL9 on the horizon and I would much rather spend my time supporting that than EL7. There are also CI constraints.

I now realize I may have been unclear, but this is support to run Foreman + Foreman Proxy (and plugins) on those platforms. With my installer hat on I focused on that. Support for managing EL7, Debian 10 and Ubuntu 18.04 using Foreman will remain supported.

I opened changes to the release notes for 3.0 and nightly that reflect these deprecations.

It leaves out any Debian changes since we need to put in effort before making that happen.

I’m not sure my phrasing there is the best it can be so please have a look.