Dropping Puppet 4 support in our installer

In our installer we include a bunch of modules. The squid module we used has dropped Puppet 4 support (which is now EOL). This means it’ll now generate errors. Using --skip-puppet-version-checks will allow you to still force it, but I’m leaning to officially dropping support. That means also raising the minimum version in packaging.

Thoughts? How many people are stuck on Puppet 4 and can’t upgrade to Puppet 5?

2 Likes

We are (actually still on Puppet 3 on a hand full of systems :blush:). But I guess we’ll have to drop support eventually.

But we already dropped version 3 in the installer. This is a different RFC from Dropping Puppet 3 in the proxy.

From my experience only few environments are Puppet 4, some are still stuck to Puppet 3, most were stuck to Puppet 3 long enough to skip Puppet 4 and directly migrate to Puppet 5.

Except from Timo’s environment I am aware of only one big NETWAYS customer with Puppet 4 and Foreman/Katello.

So I am happy with dropping Puppet 4 if it makes things easier.

We are still stuck on Puppet 4, mainly due to more urgend technical debt in other fields.
I have not maged to even look at breaking changes from 4->5->6, but from what I’ve heard it should be far less pain than the 3->4 migration.

Yes, 4 -> 5 isn’t very painful. The major version bump is mostly because of the bundled Ruby 2.4 -> 2.5 upgrade. I’ve also found one stricter scoping issue. $class::fact no longer works. See 9c0b93df3465fc218639ba917f570132f7412a9d for an example. IMHO this should have never worked. It also needs JDK 8 and I think Debian may need a debian-backports for this.

Since Puppet 4 is EOL and more of our dependencies are dropping support for it, I’m going to formalize what the modules require. That means I’m going to increase the puppet version dependency in the installer packaging.

Refactor #26340: Require at least Puppet 5.5.8 - Packaging - Foreman (Debian)
Refactor #26339: Require at least Puppet 5.5.8 - Packaging - Foreman (RPM)

2 Likes