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

[Antoine Beaupré]

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?

> The main issue remains jruby.

For the Puppet agent, from what I understand, jruby is not an
issue. jruby is an issue for puppetserver, on the other side. I think
the work here should focus on the agent since the two components are
effectively separate code bases upstream now.

> A lot of the other work has been mostly done.

I know! It's kind of amazing how hard that packaging is. :)

> At this time, maybe we should giveup on having jruby work with Ruby 3,
> and accept the parts of it which are embedded (like the ruby
> interpreter).

Yeah, that would make sense I think. But maybe that conversation would
be better to have on the jruby side of things (e.g. #972230) or in the
puppetserver ITP (#830904).

Again, I'm coming at this a little from the outside and I'm just trying
to see what the way forward is right now. Just today I had to downgrade
jetty9 after the buster point upgrade for some obscure reason, and I
can't help but think those kind of issues would go away if we kept up
with upstream a little better.

(And yes, that's an issue I should probably file somewhere... for now
that's https://gitlab.torproject.org/tpo/tpa/team/-/issues/40699 )

a.

-- 
The destiny of Earthseed is to take root among the stars.
                        - Octavia Butler