[Pkg-puppet-devel] Bug#950182: Bug#950182: Puppet 5.5 EOL in November 2020

[Antoine Beaupré]

On 2022-03-31 12:05:01, Thomas Goirand wrote:
> On 3/29/22 21:21, Antoine Beaupré wrote:
>> On 2022-03-29 21:14:42, Thomas Goirand wrote:
>>> On 3/29/22 20:58, Antoine Beaupré wrote:
>>>> On 2020-05-16 21:13:25, Martin Konrad wrote:
>>>>> Hi,
>>>>>> The others are related to other operating systems than Debian, so I
>>>>>> really wonder if we need them (yum, really? zfs and zone are for
>>>>>> Solaris, and scheduled_task is for windows...).
>>>>> If we want to make transitioning from Puppet 5 to Puppet 6 as easy as
>>>>> possible I think there is no way around packaging _all_ modules that
>>>>> were bundled with Puppet 5. Keep in mind that some users might run their
>>>>> Puppet master on Debian while having agents running on different
>>>>> operating systems that might use yum, zfs etc.
>>>>
>>>> Given how late we are to this party (Puppet 5 has been EOL over a year
>>>> now, and Puppet 6 is still not in testing), I don't think that should be
>>>> a blocker.
>>>>
>>>> It's kind of expected that major upgrades in Debian somewhat throw a
>>>> wrench in your manifests and you need to run around like a chicken with
>>>> your head cut off to plug all those leaks. That's an upstream issue, and
>>>> not one we should try to fix ourselves.
>>>>
>>>> IMHO.
>>>>
>>>> The focus here should be to provide a working Puppet 6 agent, and not
>>>> fight with the server-side stuff, which, BTW, is in an even worse shape
>>>> because the puppetserver code is not packaged *at all* in Debian
>>>> still. See:
>>>>
>>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830904
>>>> https://veronneau.org/puppetserver-6-a-debian-packaging-post-mortem.html
>>>>
>>>> Having Puppet agent 6 in Debian would at least allow us to migrate
>>>> fleets to an eventually Puppetserver 7 package in Debian bookworm, or at
>>>> least use the upstream Puppetserver 6/7 packages.
>>>>
>>>> A.
>>>
>>> Hi,
>>>
>>> I don't agree with this view.
>> 
>> Sorry, could you clarify which part you disagree with?
>
> I believe that our users would be served better if we can finish the 
> server side of things before uploading a new client with a different 
> version than the server.

My take is we are doing our users a disservice by blocking on the ideal
scenario. :) But I guess those might be irreconciliable point of views...

> We've seen how things are done upstream: it's ugly. Pushing our users to 
> move to the upstream packages is a disservice.

I think it's not great, but it's better than the status quo, which is
shipping unmaintained software to our users. We can significantly reduce
that impact by shipping at least what we can, and I believe we can ship
the agent that way.

> Maybe we can run a sprint during the coming debcamp so we can work on 
> Jruby and fix everything?

I do not plan of traveling to Kosovo this summer, unfortunately. There
is a Clojure sprint coming up in May, however, that is going to try to
address at least some of those issues:

https://wiki.debian.org/Sprints/2022/ClojureTeam

It would be great to have you there!

a.
-- 
In serious work commanding and discipline are of little avail.
                         - Peter Kropotkin