[puppet] Puppet 5 is officially unsupported in Victoria release
Hello, Just a heads up that we've had a warning in the Ussuri release about it being the last release where we are going to support Puppet 5. This patch [1] was now submitted to remove this warning and officially state that Puppet 5 is unsupported from the Victoria release. [1] https://review.opendev.org/726310?
On 5/8/20 10:56 AM, Tobias Urdin wrote:
Hello,
Just a heads up that we've had a warning in the Ussuri release about it being the
last release where we are going to support Puppet 5.
This patch [1] was now submitted to remove this warning and officially state that
Puppet 5 is unsupported from the Victoria release.
Tobias, I don't agree with this decision. Debian Buster is still with puppet 5, and puppet 6 hasn't even been uploaded to Unstable yet. How can I make you change your mind? Thomas Goirand (zigo)
On 2020-05-08 18:54:29 +0200 (+0200), Thomas Goirand wrote: [...]
I don't agree with this decision. Debian Buster is still with puppet 5, and puppet 6 hasn't even been uploaded to Unstable yet.
How can I make you change your mind?
My attempt at reading the tea leaves Puppet calls their version support matrix indicates that Puppet 5.x enters "extended support" this month and reaches EOL in November. OpenStack Victoria is scheduled to release in October, so I guess it's a question of whether the Puppet OpenStack team wants the burden of spending a cycle targeting support for a Puppet version which will be EOL the month after the release (especially given deployment projects usually release as much as a month after the coordinated release already). Debian Bullseye will probably have to release with Puppet >= 6, so hopefully it'll be in buster-backports soon after it enters testing, but it would be good to find out from Debian's Puppet package maintainers what their plans are. It looks like Puppet 6.x has been around for over a year now, hopefully it's at least on their radar. -- Jeremy Stanley
On 5/8/20 7:58 PM, Jeremy Stanley wrote:
On 2020-05-08 18:54:29 +0200 (+0200), Thomas Goirand wrote: [...]
I don't agree with this decision. Debian Buster is still with puppet 5, and puppet 6 hasn't even been uploaded to Unstable yet.
How can I make you change your mind?
My attempt at reading the tea leaves Puppet calls their version support matrix indicates that Puppet 5.x enters "extended support" this month and reaches EOL in November. OpenStack Victoria is scheduled to release in October, so I guess it's a question of whether the Puppet OpenStack team wants the burden of spending a cycle targeting support for a Puppet version which will be EOL the month after the release (especially given deployment projects usually release as much as a month after the coordinated release already).
I don't see how this can be a burden. It's not as if the language changed that much and if there was major incompatibilities. Also, even if Puppet upstream is moving, Puppet 5 will stay on Debian Buster for the life of stable, so there it will still be supported.
Debian Bullseye will probably have to release with Puppet >= 6, so hopefully it'll be in buster-backports soon after it enters testing, but it would be good to find out from Debian's Puppet package maintainers what their plans are. It looks like Puppet 6.x has been around for over a year now, hopefully it's at least on their radar.
The puppet packaging "team" is understaffed. All of the work is made by Apollon Oikonomopoulos without much help. If he needs help, I'll see how I can help him. Though indeed, we need to know what the plans are. Packaging puppet 6 is far from easy: it involves a lot of new stuff. Until we know, would very much prefer if we put this decision on hold. Cheers, Thomas Goirand (zigo)
On 2020-05-08 22:06:14 +0200 (+0200), Thomas Goirand wrote:
On 5/8/20 7:58 PM, Jeremy Stanley wrote: [...]
whether the Puppet OpenStack team wants the burden of spending a cycle targeting support for a Puppet version which will be EOL the month after the release (especially given deployment projects usually release as much as a month after the coordinated release already).
I don't see how this can be a burden. It's not as if the language changed that much and if there was major incompatibilities. [...]
Well, it does mean keeping those modules working with two major versions of Puppet which, speaking from past experience, is not easy (and a big part of why we decided to replace all our orchestration and configuration management in OpenDev with something other than Puppet after the Puppet 3->4->5 transition). How much of a strain that is on the Puppet OpenStack team, I can't say. -- Jeremy Stanley
On 5/8/20 10:24 PM, Jeremy Stanley wrote:
On 2020-05-08 22:06:14 +0200 (+0200), Thomas Goirand wrote:
On 5/8/20 7:58 PM, Jeremy Stanley wrote: [...]
whether the Puppet OpenStack team wants the burden of spending a cycle targeting support for a Puppet version which will be EOL the month after the release (especially given deployment projects usually release as much as a month after the coordinated release already).
I don't see how this can be a burden. It's not as if the language changed that much and if there was major incompatibilities. [...]
Well, it does mean keeping those modules working with two major versions of Puppet which, speaking from past experience, is not easy (and a big part of why we decided to replace all our orchestration and configuration management in OpenDev with something other than Puppet after the Puppet 3->4->5 transition).
My understanding is that adding compatibility to a new version isn't easy, but keeping compat backward isn't that hard.
How much of a strain that is on the Puppet OpenStack team, I can't say.
It means at least keeping one CI job running with puppet 5. This could be the Debian one if I succeed in restoring Debian as a voting set of jobs. Cheers, Thomas Goirand (zigo)
Hello, I don't agree, we should continue on the chosen path of not supporting Puppet 5 in the Victoria release. We've had Puppet 6 support since I introduced the testing for it in 2018 back then we ran Puppet 5 and Puppet 6 on every commit until we deemed it pretty redundant and moved Puppet 6 jobs to experimental while keeping the Puppet 6 syntax and unit jobs. We've never claimed that Puppet OpenStack is going to support downstream OS repackaging of Puppet, even though RDO/TripleO does the same we've always tested Puppet with upstream versions for our testing, only Debian has skipped that and testing with downstream packages. I don't think keeping Puppet 5 jobs for Debian would be a good idea because it would block the whole idea of moving to Puppet 6 in the first place. Puppet 5 will be EOL one month after Victoria release, while I highly doubt that we will introduce changes that will break Puppet 5 in the Victoria cycle we would like to start looking forwarding instead of being stuck with all the legacy stuff (now that we've moved to CentOS 8 as well), after being active in the project a longer time we've gone for semi-broken maintenance-mode-only to more active with keeping everything up to date and following the changes of the OpenStack community. Thanks to a number of contributors, thank you everyone! There is a lot things that we could do in Puppet OpenStack (but hey, resources to perform them is scarce) just to give an example the new Resource API [1] (whether it be with or without the usage of OpenStack CLI). If anybody ever want something to do I have nice big list of things that we could do, I've posted an old version of it in an email to this mailing list during PTL nominations. Best regards [1] https://review.opendev.org/#/q/topic:new-providers+(status:open+OR+status:me...) ________________________________________ From: Thomas Goirand <zigo@debian.org> Sent: Saturday, May 9, 2020 5:41 PM To: openstack-discuss@lists.openstack.org Subject: Re: [puppet] Puppet 5 is officially unsupported in Victoria release On 5/8/20 10:24 PM, Jeremy Stanley wrote:
On 2020-05-08 22:06:14 +0200 (+0200), Thomas Goirand wrote:
On 5/8/20 7:58 PM, Jeremy Stanley wrote: [...]
whether the Puppet OpenStack team wants the burden of spending a cycle targeting support for a Puppet version which will be EOL the month after the release (especially given deployment projects usually release as much as a month after the coordinated release already).
I don't see how this can be a burden. It's not as if the language changed that much and if there was major incompatibilities. [...]
Well, it does mean keeping those modules working with two major versions of Puppet which, speaking from past experience, is not easy (and a big part of why we decided to replace all our orchestration and configuration management in OpenDev with something other than Puppet after the Puppet 3->4->5 transition).
My understanding is that adding compatibility to a new version isn't easy, but keeping compat backward isn't that hard.
How much of a strain that is on the Puppet OpenStack team, I can't say.
It means at least keeping one CI job running with puppet 5. This could be the Debian one if I succeed in restoring Debian as a voting set of jobs. Cheers, Thomas Goirand (zigo)
On 5/9/20 8:52 PM, Tobias Urdin wrote:
Hello,
I don't agree, we should continue on the chosen path of not supporting Puppet 5 in the Victoria release.
We've had Puppet 6 support since I introduced the testing for it in 2018 back then we ran Puppet 5 and Puppet 6 on every commit until we deemed it pretty redundant and moved Puppet 6 jobs to experimental while keeping the Puppet 6 syntax and unit jobs.
We've never claimed that Puppet OpenStack is going to support downstream OS repackaging of Puppet, even though RDO/TripleO does the same we've always tested Puppet with upstream versions for our testing, only Debian has skipped that and testing with downstream packages.
I don't understand why you insist that we shouldn't use downstream distribution packages. I haven't heard that the project claimed that we are "support[ing] downstream OS repackaging of Puppet", but I haven't heard that we aren't either, or even any preference in this regard. This I miss this information somewhere? Did someone even write this somewhere? Or is this only your own view? One thing is that the Debian packages for Puppet are of better quality than the upstream ones in many ways. There's also the problem that adding an external artifact is *not* what my project is about (see below).
I don't think keeping Puppet 5 jobs for Debian would be a good idea because it would block the whole idea of moving to Puppet 6 in the first place.
What would we earn from Puppet 6? Is there some improvements in the language you would like to benefit of? We aren't even using half of what Puppet 5 offers (like typed variables, for example). Maybe we could start by that.
Puppet 5 will be EOL one month after Victoria release, while I highly doubt that we will introduce changes that will break Puppet 5 in the Victoria cycle we would like to start looking forwarding instead of being stuck with all the legacy stuff
Not having things that are breaking me is exactly what I am requesting here. So yeah, please don't break me !!! :) My installer is fully contained in Debian and contains absolutely ZERO external resources. I want to keep things this way for many reasons, including being able to ship the whole product on a redistribuable CD made by things only from Debian. I very much agree that we should move forward with Puppet 6 at some point, but in Debian, we're far from being there yet, unfortunately. Packaging Puppet 6 requires a lot of things to happen, like for example (if I'm not mistaking) having Puppet upstream to support Ruby 2.7, which is currently in Sid, plus packaging lots of Clojure stuff and so on. All I'm asking is that you delay this enough so the work can be done, and given the amount of work and my time constraint, I'm really not sure what this means, unfortunately.
If anybody ever want something to do I have nice big list of things that we could do, I've posted an old version of it in an email to this mailing list during PTL nominations.
Can you point at it so I have a look? (just the subject so I can search or any other pointer...). I have some ideas too of things I'd like to get done. For example, I have started a provider for barbican secret, in order to get swift on-disk encryption being setup automatically (this is currently a half-automated thing for me right now), and many other improvements of this kind. Have we booked some sessions for the virtual PTG? Cheers, Thomas Goirand (zigo)
On 5/10/20 12:56 AM, Thomas Goirand wrote:
On 5/9/20 8:52 PM, Tobias Urdin wrote:
Hello,
I don't agree, we should continue on the chosen path of not supporting Puppet 5 in the Victoria release.
We've had Puppet 6 support since I introduced the testing for it in 2018 back then we ran Puppet 5 and Puppet 6 on every commit until we deemed it pretty redundant and moved Puppet 6 jobs to experimental while keeping the Puppet 6 syntax and unit jobs.
We've never claimed that Puppet OpenStack is going to support downstream OS repackaging of Puppet, even though RDO/TripleO does the same we've always tested Puppet with upstream versions for our testing, only Debian has skipped that and testing with downstream packages.
I don't understand why you insist that we shouldn't use downstream distribution packages. I haven't heard that the project claimed that we are "support[ing] downstream OS repackaging of Puppet", but I haven't heard that we aren't either, or even any preference in this regard. This I miss this information somewhere? Did someone even write this somewhere? Or is this only your own view?
One thing is that the Debian packages for Puppet are of better quality than the upstream ones in many ways. There's also the problem that adding an external artifact is *not* what my project is about (see below).
One more thing: puppetlabs is only providing packages for the current stable distribution of Debian (whatever that is), never for testing or sid, and that's a perfectly valid environment where I sometimes test deployments. So if we get incompatible with Puppet 5, this also break this use case, currently. Cheers, Thomas Goirand (zigo)
Hi, IIUC the most important reason behind puppet 5 removal is that puppet 5 is EOLed soon, this month. https://puppet.com/docs/puppet/latest/about_agent.html As you know puppet-openstack has some external dependencies, this can cause the problem with our support for puppet 5. For example if any dependencies remove their compatibility with puppet 5, we should pin all of them to keep puppet 5 tests running. This is the biggest concern I know about keeping puppet 5 support. While it makes sense to use puppet 5 for existing stable branches from a stable management perspective, I don't think it's actually reasonable to extend support for EOLed stuff in master development with possibly adding pins to old modules. IMO we can delay the actual removal a bit until puppet 6 gets ready in Debian, but I'd like to hear some actual plans to have puppet 6 available in Debian so that we can expect short gap about puppet 5 eol timing, between puppet-openstack and puppet itself. Thank you, Takashi On Sun, May 10, 2020 at 8:14 AM Thomas Goirand <zigo@debian.org> wrote:
On 5/10/20 12:56 AM, Thomas Goirand wrote:
On 5/9/20 8:52 PM, Tobias Urdin wrote:
Hello,
I don't agree, we should continue on the chosen path of not supporting Puppet 5 in the Victoria release.
We've had Puppet 6 support since I introduced the testing for it in 2018 back then we ran Puppet 5 and Puppet 6 on every commit until we deemed it pretty redundant and moved Puppet 6 jobs to experimental while keeping the Puppet 6 syntax and unit jobs.
We've never claimed that Puppet OpenStack is going to support downstream OS repackaging of Puppet, even though RDO/TripleO does the same we've always tested Puppet with upstream versions for our testing, only Debian has skipped that and testing with downstream packages.
I don't understand why you insist that we shouldn't use downstream distribution packages. I haven't heard that the project claimed that we are "support[ing] downstream OS repackaging of Puppet", but I haven't heard that we aren't either, or even any preference in this regard. This I miss this information somewhere? Did someone even write this somewhere? Or is this only your own view?
One thing is that the Debian packages for Puppet are of better quality than the upstream ones in many ways. There's also the problem that adding an external artifact is *not* what my project is about (see below).
One more thing: puppetlabs is only providing packages for the current stable distribution of Debian (whatever that is), never for testing or sid, and that's a perfectly valid environment where I sometimes test deployments. So if we get incompatible with Puppet 5, this also break this use case, currently.
Cheers,
Thomas Goirand (zigo)
On 2020-05-11 21:03:00 +0900 (+0900), Takashi Kajinami wrote:
IIUC the most important reason behind puppet 5 removal is that puppet 5 is EOLed soon, this month. https://puppet.com/docs/puppet/latest/about_agent.html [...]
That information seems to conflict with https://puppet.com/docs/puppet-enterprise/product-support-lifecycle/ which indicates that PE 2018.1 enters "extended support" this month, and reaches "end of life" in November. But either way, it's not got very long, you're right. -- Jeremy Stanley
On 5/11/20 2:03 PM, Takashi Kajinami wrote:
Hi,
IIUC the most important reason behind puppet 5 removal is that puppet 5 is EOLed soon, this month. https://puppet.com/docs/puppet/latest/about_agent.html
As you know puppet-openstack has some external dependencies, this can cause the problem with our support for puppet 5. For example if any dependencies remove their compatibility with puppet 5, we should pin all of them to keep puppet 5 tests running. This is the biggest concern I know about keeping puppet 5 support.
While it makes sense to use puppet 5 for existing stable branches from a stable management perspective, I don't think it's actually reasonable to extend support for EOLed stuff in master development with possibly adding pins to old modules. IMO we can delay the actual removal a bit until puppet 6 gets ready in Debian, but I'd like to hear some actual plans to have puppet 6 available in Debian so that we can expect short gap about puppet 5 eol timing, between puppet-openstack and puppet itself.
Thank you, Takashi
Thank you, a bit more time, is the only thing I was asking for! About the plan for packaging Puppet 6 in Debian: I don't know yet, as one will have to do the work, and that's probably going to be me, since nobody is volunteering... :( Now, about dependencies: if supporting Puppet 5 gets on the way to use a newer dependency, then I suppose we can try to manage this when it happens. Worst case: forget about Puppet 5 if we get into such a bad situation. Until we're there, let's hope it doesn't happen too soon. I can tell you when I know more about the amount of work that there is to do. At the moment, it's still a bit blurry to me. Cheers, Thomas Goirand (zigo)
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 ________________________________________ From: Thomas Goirand <zigo@debian.org> Sent: Monday, May 11, 2020 5:37 PM To: openstack-discuss@lists.openstack.org Subject: Re: [puppet] Puppet 5 is officially unsupported in Victoria release On 5/11/20 2:03 PM, Takashi Kajinami wrote:
Hi,
IIUC the most important reason behind puppet 5 removal is that puppet 5 is EOLed soon, this month. https://puppet.com/docs/puppet/latest/about_agent.html
As you know puppet-openstack has some external dependencies, this can cause the problem with our support for puppet 5. For example if any dependencies remove their compatibility with puppet 5, we should pin all of them to keep puppet 5 tests running. This is the biggest concern I know about keeping puppet 5 support.
While it makes sense to use puppet 5 for existing stable branches from a stable management perspective, I don't think it's actually reasonable to extend support for EOLed stuff in master development with possibly adding pins to old modules. IMO we can delay the actual removal a bit until puppet 6 gets ready in Debian, but I'd like to hear some actual plans to have puppet 6 available in Debian so that we can expect short gap about puppet 5 eol timing, between puppet-openstack and puppet itself.
Thank you, Takashi
Thank you, a bit more time, is the only thing I was asking for! About the plan for packaging Puppet 6 in Debian: I don't know yet, as one will have to do the work, and that's probably going to be me, since nobody is volunteering... :( Now, about dependencies: if supporting Puppet 5 gets on the way to use a newer dependency, then I suppose we can try to manage this when it happens. Worst case: forget about Puppet 5 if we get into such a bad situation. Until we're there, let's hope it doesn't happen too soon. I can tell you when I know more about the amount of work that there is to do. At the moment, it's still a bit blurry to me. Cheers, Thomas Goirand (zigo)
Hello Thomas, Please see below suggestion. Best regards ________________________________________ From: Tobias Urdin <tobias.urdin@binero.com> Sent: Wednesday, May 20, 2020 11:18 AM To: openstack-discuss@lists.openstack.org Subject: Re: [puppet] Puppet 5 is officially unsupported in Victoria release 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 ________________________________________ From: Thomas Goirand <zigo@debian.org> Sent: Monday, May 11, 2020 5:37 PM To: openstack-discuss@lists.openstack.org Subject: Re: [puppet] Puppet 5 is officially unsupported in Victoria release On 5/11/20 2:03 PM, Takashi Kajinami wrote:
Hi,
IIUC the most important reason behind puppet 5 removal is that puppet 5 is EOLed soon, this month. https://puppet.com/docs/puppet/latest/about_agent.html
As you know puppet-openstack has some external dependencies, this can cause the problem with our support for puppet 5. For example if any dependencies remove their compatibility with puppet 5, we should pin all of them to keep puppet 5 tests running. This is the biggest concern I know about keeping puppet 5 support.
While it makes sense to use puppet 5 for existing stable branches from a stable management perspective, I don't think it's actually reasonable to extend support for EOLed stuff in master development with possibly adding pins to old modules. IMO we can delay the actual removal a bit until puppet 6 gets ready in Debian, but I'd like to hear some actual plans to have puppet 6 available in Debian so that we can expect short gap about puppet 5 eol timing, between puppet-openstack and puppet itself.
Thank you, Takashi
Thank you, a bit more time, is the only thing I was asking for! About the plan for packaging Puppet 6 in Debian: I don't know yet, as one will have to do the work, and that's probably going to be me, since nobody is volunteering... :( Now, about dependencies: if supporting Puppet 5 gets on the way to use a newer dependency, then I suppose we can try to manage this when it happens. Worst case: forget about Puppet 5 if we get into such a bad situation. Until we're there, let's hope it doesn't happen too soon. I can tell you when I know more about the amount of work that there is to do. At the moment, it's still a bit blurry to me. Cheers, Thomas Goirand (zigo)
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)
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)
On 5/27/20 11:54 PM, Tobias Urdin wrote:
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
Hi Tobias, Well, I am scared it breaks something indeed. Why don't you think it wont break anything with Puppet 5? If we are to continue gating on Puppet 5 (in Debian at least), what is the problem in keeping Puppet 5 in metadata.json files? Cheers, Thomas Goirand (zigo)
Hello Thomas, The version stated in metadata.json is pretty much only used to show support on PuppetForge when a module is uploaded, it could mean you cannot do "puppet module install openstack-<module>" if your puppet binary is version 5. We'd want any new users to use Puppet 6, the metadata which shows on PuppetForge would be the only place saying Puppet 5 which I don't like. Best regards ________________________________________ From: Thomas Goirand <zigo@debian.org> Sent: Thursday, May 28, 2020 10:31 AM To: openstack-discuss@lists.openstack.org Subject: Re: [puppet] Puppet 5 is officially unsupported in Victoria release On 5/27/20 11:54 PM, Tobias Urdin wrote:
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
Hi Tobias, Well, I am scared it breaks something indeed. Why don't you think it wont break anything with Puppet 5? If we are to continue gating on Puppet 5 (in Debian at least), what is the problem in keeping Puppet 5 in metadata.json files? Cheers, Thomas Goirand (zigo)
Hi Tobias, On 5/28/20 12:12 PM, Tobias Urdin wrote:
The version stated in metadata.json is pretty much only used to show support on PuppetForge when a module is uploaded, it could mean you cannot do "puppet module install openstack-<module>" if your puppet binary is version 5.
Which is probably what we don't want to forbid (yet), no? Cheers, Thomas Goirand (zigo
Hello Thomas, My proposal was that we officially state that Puppet 5 is unsupported but we dont break it for the Victoria cycle to make sure nobody actually uses Puppet 5. Best regards ________________________________________ From: Thomas Goirand <zigo@debian.org> Sent: Thursday, May 28, 2020 4:55 PM To: openstack-discuss@lists.openstack.org Subject: Re: [puppet] Puppet 5 is officially unsupported in Victoria release Hi Tobias, On 5/28/20 12:12 PM, Tobias Urdin wrote:
The version stated in metadata.json is pretty much only used to show support on PuppetForge when a module is uploaded, it could mean you cannot do "puppet module install openstack-<module>" if your puppet binary is version 5.
Which is probably what we don't want to forbid (yet), no? Cheers, Thomas Goirand (zigo
On 5/28/20 5:07 PM, Tobias Urdin wrote:
Hello Thomas,
My proposal was that we officially state that Puppet 5 is unsupported but we dont break it for the Victoria cycle to make sure nobody actually uses Puppet 5.
Best regards
That's fine then, let's go ahead. I use a packaged version of the modules as you know, so that shouldn't be breaking me as you wrote. Cheers, Thomas Goirand (zigo)
participants (4)
-
Jeremy Stanley
-
Takashi Kajinami
-
Thomas Goirand
-
Tobias Urdin