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
