Hello Thomas, Any reason why you think we should keep Puppet 5 as supported in metadata.json? I would like to prepare as much as possible this release so everything is done for the next one while it's minimal changes it would be nice to have it done already. I don't think changing that would block any Debian usage with Puppet 5. Best regards ________________________________________ From: Thomas Goirand <zigo@debian.org> Sent: Wednesday, May 27, 2020 10:45 PM To: openstack-discuss@lists.openstack.org Subject: Re: [puppet] Puppet 5 is officially unsupported in Victoria release On 5/20/20 11:18 AM, Tobias Urdin wrote:
Hello, I'm thinking that we maybe we can compromise on certain points here.
I would say it's pretty certain we would not break any Puppet 5 code in itself in the Victoria cycle since we are already behind most of the new features anyways.
What if:
* We officially state Puppet 5 is unsupported * Remove Puppet 5 as supported in metadata.json * Only run Puppet 6 integration testing for CentOS and Ubuntu
But we:
* Keep a promise to not break Puppet 5 usage in Victoria * Keep Puppet 5 unit/syntax testing (as well as Puppet 6 of course) * Debian can run integration testing with Puppet 5 if you fix those up
The benefit here is that we would not expose new consumers to use Puppet 5 but there is also drawbacks in that:
* You cannot use Puppet 5 and do a "puppet module install" since metadata.json would cause Puppet 5 to not be supported (a note here is that we don't even test that this is possible with the current state of the modules i.e checking or conflict or faulty dependencies in the metadata.json files)
Since the only issue here is that downstream Debian wants to use Puppet 5 I think this is a fair compromise and since you package the Puppet modules in Debian I assume you don't need any support being stated in metadata.json for Puppet 5 explicitly.
What do you think?
Best regards Tobias
Hi Tobias, Thanks a lot for all of the above, which I agree, except that I don't think we should remove Puppet 5 from metadata.json on all projects. I saw that today, your patch to remove Puppet 5 testing was merged. That's a good thing. Today, I've been able to make scenario001 run successfully on a Debian VM, up to the puppet 2nd run which shows indenpotancy. It later failed when running puppet, but that's because the tempest binary was set to /usr/bin/pyhon3-tempest instead of /usr/bin/tempest. In other words, I'm on very good tracks to get Debian support gating again like 2 years ago. This time, I wont give up on it and let it go, I promise! I'll also try to get a colleague be a backup of me, so we can be 2 watching on the gate if Debian was failing. FYI, to have Debian to work, we need these 2 patches: https://review.opendev.org/#/c/730881/ https://review.opendev.org/#/c/730851/ Until I get scenario001 fully working locally, these 2 are still WIP, I'll let you know on IRC when I'm done. Of course, gating in Debian is done with what I'm using, which is puppet from Debian, as you suggested. As for the packaging of Puppet in Debian Sid, the main issue is what I told you about: support for Ruby 2.7 in upstream puppet. Until this happens, it is very difficult for us to package Puppet 6. But I know upstream is actively working on it, so when it happens, I'll try to work on it myself. And when that's done, hopefully, I'll be able to backport the package to Buster, so we can gate on it. Thanks for your understanding and proposal, Cheers, Thomas Goirand (zigo)