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)