Open Stack

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 at debian.org>
Sent: Wednesday, May 27, 2020 10:45 PM
To: openstack-discuss at 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)