Puppet 5 deprecation #229
Comments
|
@voxpupuli/collaborators please provide feedback :) |
|
My only concern is how do we release new major versions for all the modules? I would expect a major release for this type of change. |
|
I agree. A major release should follow (which we also did in the past). |
|
When we drop it, we need to figure out a new minimum version. I'd recommend Puppet 6.1.0 as a lower bound. This means we can drop the If we drop it, we should also drop any compatibility code that may be present. Otherwise that just sits there and complicates the module. Some considerations:
That's why I'm in favor of holding off on dropping it in every module. I can provide a list of modules that I care about and will ensure they keep working on Puppet 5 if desired. A good reason may be that a dependency has dropped Puppet 5 support, whether released or still in git. Perhaps we can automate that check somehow. |
|
Sounds good to me. 👍 |
|
As has said a major release would be warranted it would also be nice if we could create a branch before increasing the release e.g. puppet5.x. no commitments or modsync on this branch but it would make it a little easier for people who need to use puppet 5 for a little longer to contribute any critical fixes |
this is kind of how we've dealt with 3.x |
|
We didn't do a puppet4 branch because the changes from 4 to 5 were so small. |
|
I'd prefer to leave Puppet 5 compatibility up to individual modules. I would be okay with a policy where maintainers are free to add Puppet 6 -specific features if the module benefits from them, but I on't see much value in going through Voxpupuli modules explicitly making them incompatible with Puppet 5. While it'll be unsupported by upstream, it will still be found in stable distros for a long time; and as I previously mentioned, sometimes distro packages are the only option to install Puppet on a host. |
|
👍 I am generally in favor of a (current major release) + (current major release -1) support policy. |
|
LGTM, We should have a look at modules where changes are in the pipeline which require a major melease to, and coordinate them together |
|
Of possible note, it appears that debian hasn't updated 4.x & 5.x packages to the latest upstream patch releases (stretch is still on 4.8.2 and buster is install on 5.5.10). I'm fairly skeptical that distros are going to put in the effort to backport security fixes. We should consider if we as a project are enabling this behavior. |
This is how debian , and many linux distros, work. They pick a stable release to use before going into a release freeze and then they backport and maintain all security/bug fixes. A better description of the process is here (this is ubuntu but the same or simlar holds true for debian, redhat etc) |
|
@b4ldr I understand the theory of how stabilized distro packages work. My point was that process appears to not be working for debian as they have not packaged the latest patch releases and I don't see any obvious back-porting. Nor is there, to my knowledge, any major effort to maintain major releases once they have been EOL'd by upstream that distros could draw from. In took me only seconds to find known security issues with the debian packaged versions: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7942 Users are obviously free to chose any environment. However, if someone has chosen to use Slackware 1.01 and doesn't want to invest the effort to upgrade, it doesn't mean that this project should automatically try to support that decision. |
|
For me the major reason to use the Debian distro packages is that they don't bundle a Ruby version but I'll agree that the distro versions are in a sad state. That is my impression of the overall state of Puppet in the open source world. It appears most users have moved on. Those still using it are often in stable environments where little changes. |
|
The "upstream moves too fast for distro packaging problem" is what SCLs and modularity/streams support in el8/fedora are trying to solve. It would be nice if the official packages would take advantage of either of these solutions. I have long used the foreman SCL which once upon a time even packaged puppet. I am in the camp that believes stabilized distros can't reasonably support "fast" moving projects and the limited effort available could be used much more productively than trying to do things such as de-vendorizing k8s libs. Complex apps like k8s should be running in containers anyways (E.g. |
|
I agree that it would be nice if Puppet used SCLs on EL7. Puppet's RPM packages are dreadful. Sadly, they invented their own packaging solution so I can't provide any patches. My bug reports have generally gone unanswered or closed with WONTFIX. If it wasn't for distro packages there's a good chance I would simply stop using Puppet. |
|
It is essentially the opposite for me. Bare metal hosts have a puppet yum repo mirror setup and the agent installed as part of kickstart. What the distro packages or doesn't isn't really a significant impact as there are a fair number of non-distro repos that have to be managed anyways. The majority, but not all, of applications have migrated to containers/k8s and are outside the scope of puppet. |
Sid has 5.5.22 https://packages.debian.org/source/sid/puppet which seems to be the current patch release and work is underway to package puppet6 for bullseye
This one is being tracked
This is claimed to be fixed and the patch is in the git repo So sure not perfect but i think its disingenuous to say "that process appears to not be working for debian" |
|
i second @jhoblitt general strategy proposal of a (current major release) + (current major release -1) support policy. With the added addendum that both versions need to be in support. So with puppet 7 only being freshly released i would say its the right time to start the discussion but perhaps not to pull the trigger as yet but there are only a couple more weeks of puppet 5 support left so respite wont be to long. I generally only track/consider the upsteam puppet inc repos as many of us have remarked the distro packages are lagging behind significantly. Also not releasing puppet 5 on ubuntu 20.04 by puppet inc to me signals (perhaps incorrectly) intend for a quick "stage left" exit for Puppet 5 on their end. So for the the time being i would second @igalic suggestion to move puppet5 support into a branch but remove puppet 5 support from the main/master branch. And let individual contributors to repos decide how long they are willing to take the engineering time/cost of maintaining puppet 5 support |
Back then Puppet 5 was the LTS release. Just as that they did build puppet-agent for Puppet 5 but not puppetserver 5 on Debian 10. I still don't understand how they made those choices. Still frustrates me and since there was no real good explanation IIRC (other than "we just don't want to"). If there was a technical reason, it would be much easier to understand. |
|
my distro just dropped a puppet7 release four days ago but i haven't had time to update yet… |
|
Do we have a consensus in the text on #232? |
|
quite uncool as puppet 5.5 is shipped with debian stable (buster). version rushing is quite a bad thing :( |
This issue is a result of #228
Puppet 5 will be end of live soonish. In the past, when Puppet 3 and Puppet 4 were end of live, we removed them from the metadata.json. I propose we do the same with Puppet 5 now. Since our modulesync_config release 4, we generate our acceptance tests based on operating systems in metadata.json and the puppet versions in metadata.json. his means as soon as we drop Puppet 5 from metadata.json, we also stop running our unit tests on it.
Benefits:
The text was updated successfully, but these errors were encountered: