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.

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

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

Cheers,

Thomas Goirand (zigo)

Reply via email to