<div dir="ltr"><div dir="ltr">Hi,<br><br><br>IIUC the most important reason behind puppet 5 removal is that puppet 5<br>is EOLed soon, this month.<br> <a href="https://puppet.com/docs/puppet/latest/about_agent.html">https://puppet.com/docs/puppet/latest/about_agent.html</a><br><br>As you know puppet-openstack has some external dependencies, this can<br>cause the problem with our support for puppet 5.<br>For example if any dependencies remove their compatibility with puppet 5,<br>we should pin all of them to keep puppet 5 tests running.<br>This is the biggest concern I know about keeping puppet 5 support.<br><br>While it makes sense to use puppet 5 for existing stable branches from a stable<br>management perspective, I don't think it's actually reasonable to extend support<br>for EOLed stuff in master development with possibly adding pins to old modules.<br>IMO we can delay the actual removal a bit until puppet 6 gets ready in Debian,<br>but I'd like to hear some actual plans to have puppet 6 available in Debian<br>so that we can expect short gap about puppet 5 eol timing, between puppet-openstack<br>and puppet itself.<br><br>Thank you,<br>Takashi</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 10, 2020 at 8:14 AM Thomas Goirand <<a href="mailto:zigo@debian.org">zigo@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 5/10/20 12:56 AM, Thomas Goirand wrote:<br>
> On 5/9/20 8:52 PM, Tobias Urdin wrote:<br>
>> Hello,<br>
>><br>
>> I don't agree, we should continue on the chosen path of not supporting Puppet 5<br>
>> in the Victoria release.<br>
>><br>
>> We've had Puppet 6 support since I introduced the testing for it in 2018 back then we ran<br>
>> Puppet 5 and Puppet 6 on every commit until we deemed it pretty redundant and moved<br>
>> Puppet 6 jobs to experimental while keeping the Puppet 6 syntax and unit jobs.<br>
>><br>
>> We've never claimed that Puppet OpenStack is going to support downstream OS repackaging of<br>
>> Puppet, even though RDO/TripleO does the same we've always tested Puppet with upstream<br>
>> versions for our testing, only Debian has skipped that and testing with downstream packages.<br>
> <br>
> I don't understand why you insist that we shouldn't use downstream<br>
> distribution packages. I haven't heard that the project claimed that we<br>
> are "support[ing] downstream OS repackaging of Puppet", but I haven't<br>
> heard that we aren't either, or even any preference in this regard. This<br>
> I miss this information somewhere? Did someone even write this<br>
> somewhere? Or is this only your own view?<br>
> <br>
> One thing is that the Debian packages for Puppet are of better quality<br>
> than the upstream ones in many ways. There's also the problem that<br>
> adding an external artifact is *not* what my project is about (see below).<br>
<br>
One more thing: puppetlabs is only providing packages for the current<br>
stable distribution of Debian (whatever that is), never for testing or<br>
sid, and that's a perfectly valid environment where I sometimes test<br>
deployments. So if we get incompatible with Puppet 5, this also break<br>
this use case, currently.<br>
<br>
Cheers,<br>
<br>
Thomas Goirand (zigo)<br>
<br>
</blockquote></div></div>