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

[Louis-Philippe Véronneau]

On 2022-03-31 09 h 17, Antoine Beaupré wrote:
> 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.

I agree with Antoine on this. I don't think we'll be able to get
puppetserver in bookworm before the freeze (in less than 1 year).

Might as well get the agent up to date, as there are no blockers for it.

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

Sadly, I don't believe this issue can be solved in such a short lapse of
time.

Maybe I'm pessimistic, but I sunk quite a lot of time in trying to fix
jruby myself and:

1. It's a very complex package
2. It clashes with existing ruby packages in Debian in multiple ways
3. It requires good knowledge of both the Ruby and Java ecosystem

Chances are I'll be in Kosovo, but I don't think I'll have any time to
work on jruby.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   pollo at debian.org / veronneau.org
  ⠈⠳⣄