Lines indicated with * require Parametrized_Classes_in_ENC in Foreman to be disabled.
I would like to propose that we officially drop support for all versions of Puppet < 4.0. If that’s too soon for 1.18, then that’s okay. This actually feels more like a 2.0 change. I’ve put together a high level walkthrough of how this should most likely be carried out.
The first step would be to remove all testing of those puppet versions in Jenkins amongst our plethora of jobs. This would reduce load. Our documentation should also be combed to check for any references to older versions.
Next, any legacy code that stayed around to support older versions of Puppet should be refactored and/or removed.
Again, this is extremely high-level at the moment, but anyone with feedback on yet discussed effects of dropping support, or of other areas that will need attention, please chime in and I’ll start putting together a more detailed game plan. Thanks!
@Gwmngilfen might have stats re: puppet use which would help to make this decision.
Can’t speak for the Foreman itself, but as far as Smart-Proxy is concerned, if we ship functionality we should have tests and run them. For more context: for puppet versions < 4, smart-proxy relies on custom code for environment and class enumeration. While chances are low that things would suddenly break, I don’t think we should stop running tests while this code is still present.
Next, any legacy code that stayed around to support older versions of Puppet should be refactored and/or removed.
Should be pretty trivial (in Smart-Proxy) – it is all isolated in a dedicated module. Installer/puppet modules are a different story.
Kafo (and kafo_parsers in particular) could drop the non-puppet-strings backend. If we move our modules to Yardoc (instead of the current rdoc) and get group support into puppet-strings then we could probably drop kafo_parsers and just consume the JSON output from puppet-strings in Kafo. A while back I toyed with this and it looked feasible. I’ll try to open the discussion with upstream puppet-strings about the group support.
Why do we want to drop support for the old versions? I believe there are still users on 3.x and I am wondering if the effort to support these versions is really that big. I’d suggest to keep support for 3.x clients and puppetmasters as long as it’s feasible.
If you throw in the 2.6% for “Significant mix” then we have over 20% of the community still making use of Puppet 3. This doesn’t surprise me - the upgrade to Puppet 4 is horrible, and enterprises are often slow to upgrade at the best of times.
My gut feeling is that it’s OK to say “this is old now, and it’s therefore unsupported”, stop the tests, but actually leave the code in for a while longer. I’m OK with not testing that since we have plenty of other stuff we ship that we don’t do much testing on (cough compute resources cough) and we rely on community involvement to keep it working. This is no different, I think.
I think there’s no argument that puppet <3.0 can be dropped immediately in 1.18. That would already allow us to drop some of the versions from the testing and some of the code (although these changes most likely will only be in 1.19). Since 3 seems to be still used fairly heavily, I think we should give our users at least one version to plan their upgrade path (similar to what we did when dropping el6).
So that would mean that:
1.18 will officially support only 3.0+, while stating that it will be the last version to do so. Older versions will be marked as untested.
1.19 will make <3.0 unsupported and 3.x either untested or unsupported, depending on when the code that is used to support it is actually removed.
1.20/2.0/ will only support 4+ and all other versions will be unsupported.
@Gwmngilfen do you happen to have more exact numbers? I would especially be interested in a distribution of Puppet3 between <3.6, 3.6 and 3.8. My gut-feeling would be it’s safe to drop <3.8 today. But I might be wrong.
I’d say we explicitly drop anything older than Puppet 3.8 for 1.18. It’s long EOL and while I realize that the upgrade is painful, we can’t keep it alive forever. The ecosystem is moving on and I see it as a waste of resources to keep it alive.
Side note: Puppet 4 is planned to be EOL in October 2018.
Considering we aren’t going to add any changes regarding this in 1.18 anyways at this point, I think there’s no harm leaving puppet < 3 as untested and puppet 3.x as supported but deprecated, and giving anyone still holding out on puppet 3 a bit longer to prepare for the upgrade. 1.19 which should be out in ~3-4 months will already require a minimum of puppet 4.
If this is acceptable to everyone, this means - Let the code deletion begin! I’m sure there’s a bunch of stuff that can be removed both in @core and in @proxy that was needed for puppet <4 support
