Debian Bug report logs - #950182
Puppet 5.5 EOL in November 2020

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupre <anarcat@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: Puppet 5.5 EOL in November 2020

Date: Wed, 29 Jan 2020 15:50:35 -0500

Package: puppet
Version: 5.5.10-4
Severity: important

Puppet 5.5 will reach end of life in November 2020, before Debian
Buster does (~2022):

https://puppet.com/docs/puppet/5.5/about_agent.html

(Since this page can basically disappear at any time in the future
(because they regularly archive those and break those links), here's
what's supposed to be a permanent link for that:

https://puppet.com/docs/puppet/latest/about_agent.html

... and since they manage to break that as well often, here are IA
links for both:

https://web.archive.org/web/20200129203719/https://puppet.com/docs/puppet/5.5/about_agent.html
https://web.archive.org/web/20200129203732/https://puppet.com/docs/puppet/latest/about_agent.html

...)

Anyways. The point is, our Puppets will die a horrible death. Poor
little inanimate creatures! What should we do about our little
favorite cloths! Should we forget about them in the bottom drawer of a
dusty filing cabinet? Throw them in a ritual fire and hope for the
best?

No! We should figure out a way to provide an upstream-supported
version of Puppet somehow.

The first stage of this would probably be to package Puppet 6 and ship
it in Bullseye.

From what I can tell from the release notes:

https://puppet.com/docs/puppet/6.0/release_notes_puppet.html

... the upgrade from 5 to 6 doesn't involve much churn in the DSL, so
it's not as big of a deal as the 3 to 4 or 4 to 5 migrations we had to
suffer through. The tooling does change, however, so it might be
tricky on the packaging side (which is why, I am guessing, P6 is not
yet in Debian).

(The release notes do mention we now require Ruby 2.3, but that's not
a problem: we've had that for a while in Debian now. And I suspect
there must be some atrocities hidden behind PuppetDB coming up, so far
I'm plugging my ears and signing "la la la everything is written in C
i can't hear you".)

Once we land in testing, maybe we could provide a backport, or
convince the release team to forcibly upgrade people to Puppet 6
(gasp!) in buster, if that upgrade is indeed non-destructive, so that
we do have security support for a longer period there...

(Now what is *really* hilarious about all this is that upgrading to
Puppet 6 does *not* actually give us a better support window right
now: the latest 6.x release EOL date is *August* 2020, *before* the
Puppet 5.5 EOL time. This is utterly incomprehensible to me. From what
I can tell in their support docs:

https://puppet.com/docs/puppet-enterprise/product-support-lifecycle/

... they seem to be saying they release a LTS every two years, with a
six month (!!) overlap between the two "so you have time to test your
upgrade prior to the next LTS release". I don't quite understand how
they can possibly imagine we upgrade an entire fleet of Puppet servers
and large manifests in six months, but maybe that's just me...

It seems the perfect match for Debian and Puppet support windows would
be this impossible world when Puppet would release an LTS at exactly
the same time Debian would ship a release (and that it would be
instantly packaged and shipped in that release as well of
course). Then the Puppet release would be supported for 2 years and 6
months, which is roughly our support window for core stable releases
in Debian as well these days... But of course, that's basically
impossible so we'll have to find long-term ways of dealing with this
problem.)

Note that I'm ignoring the oldstable and oldoldstable releases here,
which both ship completely unsupported upstream releases (4.8 and 3.7,
respectively), and for which we don't have a good user story either.

-- System Information:
Debian Release: 10.2
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages puppet depends on:
ii  adduser              3.118
ii  facter               3.11.0-2+deb10u1
ii  hiera                3.2.0-2
ii  init-system-helpers  1.56+nmu1
ii  lsb-base             10.2019051400
ii  ruby                 1:2.5.1
ii  ruby-augeas          1:0.5.0-3+b6
ii  ruby-deep-merge      1.1.1-1
ii  ruby-shadow          2.5.0-1+b1

Versions of packages puppet recommends:
ii  debconf-utils  1.5.71
ii  lsb-release    10.2019051400
ii  ruby-selinux   2.8-1+b1

Versions of packages puppet suggests:
pn  ruby-hocon  <none>
pn  ruby-rrd    <none>

-- debconf-show failed

Message #10 received at 950182@bugs.debian.org (full text, mbox, reply):

From: Stig Sandbeck Mathisen <ssm@debian.org>

To: Antoine Beaupre <anarcat@debian.org>

Cc: 950182@bugs.debian.org

Subject: Re: Bug#950182: Puppet 5.5 EOL in November 2020

Date: Thu, 30 Jan 2020 07:23:11 +0100

Antoine Beaupre <anarcat@debian.org> writes:

> ... the upgrade from 5 to 6 doesn't involve much churn in the DSL, so
> it's not as big of a deal as the 3 to 4 or 4 to 5 migrations we had to
> suffer through. The tooling does change, however, so it might be
> tricky on the packaging side (which is why, I am guessing, P6 is not
> yet in Debian).

The biggest difference I've seen between Puppet 5 and 6 is that many
previously built-in resource types have moved from the puppet repository
to external modules. Puppet include those in their own packaging. We
will have to package those as well, and add them as dependencies.

From a user point of view, the missing modules mainly shows up when
doing rspec module testing. I need to add those modules to the test
fixtures when using Puppet 6.

-- 
Stig Sandbeck Mathisen
Debian Developer

Message #15 received at 950182@bugs.debian.org (full text, mbox, reply):

From: Thomas Goirand <zigo@debian.org>

To: 950182@bugs.debian.org

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

Date: Thu, 30 Jan 2020 09:20:53 +0100

On 1/30/20 7:23 AM, Stig Sandbeck Mathisen wrote:
> Antoine Beaupre <anarcat@debian.org> writes:
> 
>> ... the upgrade from 5 to 6 doesn't involve much churn in the DSL, so
>> it's not as big of a deal as the 3 to 4 or 4 to 5 migrations we had to
>> suffer through. The tooling does change, however, so it might be
>> tricky on the packaging side (which is why, I am guessing, P6 is not
>> yet in Debian).
> 
> The biggest difference I've seen between Puppet 5 and 6 is that many
> previously built-in resource types have moved from the puppet repository
> to external modules. Puppet include those in their own packaging. We
> will have to package those as well, and add them as dependencies.

Could you list them? I'd be ok to do that work within the team, if
someone else is working on Puppet itself.

> From a user point of view, the missing modules mainly shows up when
> doing rspec module testing.

So, we're talking about Ruby stuff?

Cheers,

Thomas Goirand (zigo)

Message #20 received at 950182@bugs.debian.org (full text, mbox, reply):

From: Stig Sandbeck Mathisen <ssm@debian.org>

To: Thomas Goirand <zigo@debian.org>

Cc: 950182@bugs.debian.org

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

Date: Sat, 01 Feb 2020 10:51:42 +0100

Thomas Goirand <zigo@debian.org> writes:

> Could you list them? I'd be ok to do that work within the team, if
> someone else is working on Puppet itself.

From the "puppet-agent" repository, at
https://github.com/puppetlabs/puppet-agent/blob/6.4.x/configs/projects/puppet-agent.rb#L116

puppetlabs-augeas_core https://forge.puppet.com/puppetlabs/augeas_core
puppetlabs-cron_core https://forge.puppet.com/puppetlabs/cron_core
puppetlabs-host_core https://forge.puppet.com/puppetlabs/host_core
puppetlabs-mount_core https://forge.puppet.com/puppetlabs/mount_core
puppetlabs-sshkeys_core https://forge.puppet.com/puppetlabs/sshkeys_core
puppetlabs-selinux_core https://forge.puppet.com/puppetlabs/selinux_core
puppetlabs-yumrepo_core https://forge.puppet.com/puppetlabs/yumrepo_core
puppetlabs-zfs_core https://forge.puppet.com/puppetlabs/zfs_core
puppetlabs-zone_core https://forge.puppet.com/puppetlabs/zone_core
puppetlabs-scheduled_task https://forge.puppet.com/puppetlabs/scheduled_task

>> From a user point of view, the missing modules mainly shows up when
>> doing rspec module testing.
>
> So, we're talking about Ruby stuff?

The resource types and provides are written in ruby, but distributed as
puppet modules.

When testing puppet modules, and your code use the "cron", "host",
"mount" (from the list above) resource types, they need to be present.

The resource types are present in the puppet 5 source repository, while
in puppet 6, they are maintained as separate puppet modules in their own
repositories, and we would need to add them as packaged dependencies.

--
Stig Sandbeck Mathisen
Debian Developer

Message #25 received at 950182@bugs.debian.org (full text, mbox, reply):

From: Thomas Goirand <zigo@debian.org>

To: Stig Sandbeck Mathisen <ssm@debian.org>

Cc: 950182@bugs.debian.org

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

Date: Sun, 2 Feb 2020 13:06:42 +0100

On 2/1/20 10:51 AM, Stig Sandbeck Mathisen wrote:
> Thomas Goirand <zigo@debian.org> writes:
> 
>> Could you list them? I'd be ok to do that work within the team, if
>> someone else is working on Puppet itself.
> 
>>From the "puppet-agent" repository, at
> https://github.com/puppetlabs/puppet-agent/blob/6.4.x/configs/projects/puppet-agent.rb#L116
> 
> puppetlabs-augeas_core https://forge.puppet.com/puppetlabs/augeas_core
> puppetlabs-cron_core https://forge.puppet.com/puppetlabs/cron_core
> puppetlabs-host_core https://forge.puppet.com/puppetlabs/host_core
> puppetlabs-mount_core https://forge.puppet.com/puppetlabs/mount_core
> puppetlabs-sshkeys_core https://forge.puppet.com/puppetlabs/sshkeys_core
> puppetlabs-selinux_core https://forge.puppet.com/puppetlabs/selinux_core
> puppetlabs-yumrepo_core https://forge.puppet.com/puppetlabs/yumrepo_core
> puppetlabs-zfs_core https://forge.puppet.com/puppetlabs/zfs_core
> puppetlabs-zone_core https://forge.puppet.com/puppetlabs/zone_core
> puppetlabs-scheduled_task https://forge.puppet.com/puppetlabs/scheduled_task
> 
>>> From a user point of view, the missing modules mainly shows up when
>>> doing rspec module testing.
>>
>> So, we're talking about Ruby stuff?
> 
> The resource types and provides are written in ruby, but distributed as
> puppet modules.
> 
> When testing puppet modules, and your code use the "cron", "host",
> "mount" (from the list above) resource types, they need to be present.
> 
> The resource types are present in the puppet 5 source repository, while
> in puppet 6, they are maintained as separate puppet modules in their own
> repositories, and we would need to add them as packaged dependencies.
> 
> --
> Stig Sandbeck Mathisen
> Debian Developer
> 

FYI, I packaged and uploaded the first 2 so far, but can't push to Git.
Please set me as maintainer or owner, so I can do that.

Note that I'm doing a git based workflow, packaging upstream tags,
rather than using pristine-tar. If this bothers anyone, please let me
know (but please only complain about the workflow if you really have the
intention to contribute to the packaging, otherwise you're just getting
on my way to be efficient for no reason).

Cheers,

Thomas Goirand (zigo)

Message #30 received at 950182@bugs.debian.org (full text, mbox, reply):

From: Stig Sandbeck Mathisen <ssm@debian.org>

To: Thomas Goirand <zigo@debian.org>

Cc: Stig Sandbeck Mathisen <ssm@debian.org>, 950182@bugs.debian.org

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

Date: Mon, 03 Feb 2020 16:16:51 +0100

Thomas Goirand <zigo@debian.org> writes:

> Note that I'm doing a git based workflow, packaging upstream tags,
> rather than using pristine-tar. If this bothers anyone, please let me
> know (but please only complain about the workflow if you really have
> the intention to contribute to the packaging, otherwise you're just
> getting on my way to be efficient for no reason).

I'm moving from pristine-tar to git based workflows for my own things,
and getting more and more impressed with dgit, so I won't complain. :)

-- 
Stig Sandbeck Mathisen
Debian Developer

Message #35 received at 950182@bugs.debian.org (full text, mbox, reply):

From: Thomas Goirand <zigo@debian.org>

To: 950182@bugs.debian.org

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

Date: Mon, 3 Feb 2020 16:54:43 +0100

On 2/2/20 1:06 PM, Thomas Goirand wrote:
> On 2/1/20 10:51 AM, Stig Sandbeck Mathisen wrote:
>> Thomas Goirand <zigo@debian.org> writes:
>>
>>> Could you list them? I'd be ok to do that work within the team, if
>>> someone else is working on Puppet itself.
>>
>> >From the "puppet-agent" repository, at
>> https://github.com/puppetlabs/puppet-agent/blob/6.4.x/configs/projects/puppet-agent.rb#L116
>>
>> puppetlabs-augeas_core https://forge.puppet.com/puppetlabs/augeas_core
>> puppetlabs-cron_core https://forge.puppet.com/puppetlabs/cron_core
>> puppetlabs-host_core https://forge.puppet.com/puppetlabs/host_core
>> puppetlabs-mount_core https://forge.puppet.com/puppetlabs/mount_core
>> puppetlabs-sshkeys_core https://forge.puppet.com/puppetlabs/sshkeys_core
>> puppetlabs-selinux_core https://forge.puppet.com/puppetlabs/selinux_core
>> puppetlabs-yumrepo_core https://forge.puppet.com/puppetlabs/yumrepo_core
>> puppetlabs-zfs_core https://forge.puppet.com/puppetlabs/zfs_core
>> puppetlabs-zone_core https://forge.puppet.com/puppetlabs/zone_core
>> puppetlabs-scheduled_task https://forge.puppet.com/puppetlabs/scheduled_task
>>
>>>> From a user point of view, the missing modules mainly shows up when
>>>> doing rspec module testing.
>>>
>>> So, we're talking about Ruby stuff?
>>
>> The resource types and provides are written in ruby, but distributed as
>> puppet modules.
>>
>> When testing puppet modules, and your code use the "cron", "host",
>> "mount" (from the list above) resource types, they need to be present.
>>
>> The resource types are present in the puppet 5 source repository, while
>> in puppet 6, they are maintained as separate puppet modules in their own
>> repositories, and we would need to add them as packaged dependencies.
>>
>> --
>> Stig Sandbeck Mathisen
>> Debian Developer
>>
> 
> FYI, I packaged and uploaded the first 2 so far, but can't push to Git.
> Please set me as maintainer or owner, so I can do that.
> 
> Note that I'm doing a git based workflow, packaging upstream tags,
> rather than using pristine-tar. If this bothers anyone, please let me
> know (but please only complain about the workflow if you really have the
> intention to contribute to the packaging, otherwise you're just getting
> on my way to be efficient for no reason).
> 
> Cheers,
> 
> Thomas Goirand (zigo)

Heya,

I'm not sure who did it, but I do have the "maintainer" rights on
Gitlab, so everything looks fine to me.

I have built and uploaded:

puppetlabs-augeas_core https://forge.puppet.com/puppetlabs/augeas_core
puppetlabs-cron_core https://forge.puppet.com/puppetlabs/cron_core
puppetlabs-host_core https://forge.puppet.com/puppetlabs/host_core
puppetlabs-mount_core https://forge.puppet.com/puppetlabs/mount_core
puppetlabs-sshkeys_core https://forge.puppet.com/puppetlabs/sshkeys_core
puppetlabs-selinux_core https://forge.puppet.com/puppetlabs/selinux_core

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...).

Augeas and Cron are already in Sid. I wonder if the FTP masters are in
the need for these... :P

Cheers,

Thomas Goirand (zigo)

Message #40 received at 950182@bugs.debian.org (full text, mbox, reply):

From: Martin Konrad <info@martin-konrad.net>

To: 950182@bugs.debian.org

Subject: Bug#950182: Puppet 5.5 EOL in November 2020

Date: Sat, 16 May 2020 21:13:25 -0400

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.

Cheers,

Martin

Message #45 received at 950182@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Martin Konrad <info@martin-konrad.net>, 950182@bugs.debian.org, 950182@bugs.debian.org

Subject: Re: Bug#950182: Puppet 5.5 EOL in November 2020

Date: Tue, 29 Mar 2022 14:58:52 -0400

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.

-- 
Instead of worrying about what somebody else is going to do, which is
not under your control, the important thing is, what are you going to
decide about what is under your control?
                         - Richard Stallman

Message #50 received at 950182@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Thomas Goirand <zigo@debian.org>, 950182@bugs.debian.org, Stig Sandbeck Mathisen <ssm@debian.org>

Cc: 950182@bugs.debian.org

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

Date: Tue, 29 Mar 2022 15:08:30 -0400

On 2020-02-02 13:06:42, Thomas Goirand wrote:

[...]

> FYI, I packaged and uploaded the first 2 so far, but can't push to Git.
> Please set me as maintainer or owner, so I can do that.
>
> Note that I'm doing a git based workflow, packaging upstream tags,
> rather than using pristine-tar. If this bothers anyone, please let me
> know (but please only complain about the workflow if you really have the
> intention to contribute to the packaging, otherwise you're just getting
> on my way to be efficient for no reason).

Not sure I'm picking the right message to reply to here, but here we go.

I see that you uploaded 6.16.0-1 to experimental back in December 2020:

https://tracker.debian.org/news/1205795/accepted-puppet-6160-1-source-into-experimental/

Is that package in any shape to ship with bookworm? It would be great to
start this transition to get the package down into testing soon...

Note that we're likely to miss the February 2023 deadline for the Puppet
6 EOL anyways:

https://puppet.com/docs/puppet/6/platform_lifecycle.html

... so maybe we don't even want to do that? or maybe we should focus on
packaging Puppet 7?

I was hoping for a moment we could ship bookworm with the Puppet 6 agent
which would allow us work with a puppetserver 7, but it seems even that
won't keep us from shipping an EOL component (puppet agent 6)...

a.
-- 
La mer, cette grande unificatrice, est l'unique espoir de l'homme.
Aujourd'hui plus que jamais auparavant, ce vieux dicton dit
littéralement ceci: nous sommes tous dans le même bateau.
                        - Jacques Yves Cousteau - Océanographe

Message #55 received at 950182@bugs.debian.org (full text, mbox, reply):

From: Thomas Goirand <zigo@debian.org>

To: Antoine Beaupré <anarcat@debian.org>, 950182@bugs.debian.org, Martin Konrad <info@martin-konrad.net>

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

Date: Tue, 29 Mar 2022 21:14:42 +0200

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.

The main issue remains jruby. A lot of the other work has been mostly 
done. 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).

Cheers,

Thomas Goirand (zigo)

Message #60 received at 950182@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Thomas Goirand <zigo@debian.org>, 950182@bugs.debian.org, Martin Konrad <info@martin-konrad.net>

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

Date: Tue, 29 Mar 2022 15:21:52 -0400

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

Message #65 received at 950182@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: 950182@bugs.debian.org, Thomas Goirand <zigo@debian.org>, 950182@bugs.debian.org, Martin Konrad <info@martin-konrad.net>

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

Date: Wed, 30 Mar 2022 14:34:08 -0400

On 2022-03-29 15:21:52, Antoine Beaupré wrote:

[...]

> 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 )

It was actually already filed as #994843.

-- 
C'est trop facile quand les guerres sont finies
D'aller gueuler que c'était la dernière
Amis bourgeois vous me faites envie
Ne voyez vous pas donc point vos cimetières?
                        - Jaques Brel

Message #70 received at 950182@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Thomas Goirand <zigo@debian.org>, 950182@bugs.debian.org, Martin Konrad <info@martin-konrad.net>

Cc: 830904@bugs.debian.org

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

Date: Wed, 30 Mar 2022 16:28:40 -0400

On 2022-03-29 15:21:52, Antoine Beaupré wrote:
> On 2022-03-29 21:14:42, Thomas Goirand wrote:

[...]

>> 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).

I've actually opened up a discussion about this in:

https://alioth-lists.debian.net/pipermail/pkg-puppet-devel/2022-March/012662.html

-- 
What people say, what people do, and what they say they do are
entirely different things.
                        - Margaret Mead

Message #75 received at 950182@bugs.debian.org (full text, mbox, reply):

From: Thomas Goirand <zigo@debian.org>

To: Antoine Beaupré <anarcat@debian.org>, 950182@bugs.debian.org, Martin Konrad <info@martin-konrad.net>

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

Date: Thu, 31 Mar 2022 12:05:01 +0200

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)

Message #80 received at 950182@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Thomas Goirand <zigo@debian.org>, 950182@bugs.debian.org, Martin Konrad <info@martin-konrad.net>

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

Date: Thu, 31 Mar 2022 09:17:27 -0400

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

Message #85 received at 950182@bugs.debian.org (full text, mbox, reply):

From: Thomas Goirand <zigo@debian.org>

To: Antoine Beaupré <anarcat@debian.org>, 950182@bugs.debian.org, Stig Sandbeck Mathisen <ssm@debian.org>

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

Date: Thu, 31 Mar 2022 17:05:19 +0200

On 3/29/22 21:08, Antoine Beaupré wrote:
> On 2020-02-02 13:06:42, Thomas Goirand wrote:
> 
> [...]
> 
>> FYI, I packaged and uploaded the first 2 so far, but can't push to Git.
>> Please set me as maintainer or owner, so I can do that.
>>
>> Note that I'm doing a git based workflow, packaging upstream tags,
>> rather than using pristine-tar. If this bothers anyone, please let me
>> know (but please only complain about the workflow if you really have the
>> intention to contribute to the packaging, otherwise you're just getting
>> on my way to be efficient for no reason).
> 
> Not sure I'm picking the right message to reply to here, but here we go.
> 
> I see that you uploaded 6.16.0-1 to experimental back in December 2020:
> 
> https://tracker.debian.org/news/1205795/accepted-puppet-6160-1-source-into-experimental/
> 
> Is that package in any shape to ship with bookworm? It would be great to
> start this transition to get the package down into testing soon...

Uploading it will break current puppet-master. Unless we have a solution 
to replace it, I don't want to do that...

Cheers,

Thomas Goirand (zigo)

Message #90 received at 950182@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Thomas Goirand <zigo@debian.org>, 950182@bugs.debian.org, Stig Sandbeck Mathisen <ssm@debian.org>

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

Date: Thu, 31 Mar 2022 11:24:34 -0400

On 2022-03-31 17:05:19, Thomas Goirand wrote:
> On 3/29/22 21:08, Antoine Beaupré wrote:
>> On 2020-02-02 13:06:42, Thomas Goirand wrote:
>> 
>> [...]
>> 
>>> FYI, I packaged and uploaded the first 2 so far, but can't push to Git.
>>> Please set me as maintainer or owner, so I can do that.
>>>
>>> Note that I'm doing a git based workflow, packaging upstream tags,
>>> rather than using pristine-tar. If this bothers anyone, please let me
>>> know (but please only complain about the workflow if you really have the
>>> intention to contribute to the packaging, otherwise you're just getting
>>> on my way to be efficient for no reason).
>> 
>> Not sure I'm picking the right message to reply to here, but here we go.
>> 
>> I see that you uploaded 6.16.0-1 to experimental back in December 2020:
>> 
>> https://tracker.debian.org/news/1205795/accepted-puppet-6160-1-source-into-experimental/
>> 
>> Is that package in any shape to ship with bookworm? It would be great to
>> start this transition to get the package down into testing soon...
>
> Uploading it will break current puppet-master. Unless we have a solution 
> to replace it, I don't want to do that...

I understand that, but my perspective is that we *want* to break the
current, 5.5 puppet master. We do *not* want to ship that in
bookworm. So breaking it is acceptable in that sense, to me.

But I guess it's pointless to keep arguing that same point. :)

-- 
The survival of humans and other species on planet Earth in my view can
only be guaranteed via a timely transition towards a stationary
state, a world economy without growth.
                         - Peter Custers

Message #95 received at 950182@bugs.debian.org (full text, mbox, reply):

From: Gabriel Filion <gabster@lelutin.ca>

To: 950182@bugs.debian.org

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

Date: Thu, 14 Apr 2022 10:12:25 -0400

Hi there,

I'm just chiming in to add yet another object on the scale:

in current debian testing, ruby has been transitioned to 3.0 and judging 
from the release history, puppet has not added support for ruby 3.0 
until 7.8.0:

https://puppet.com/docs/puppet/7/release_notes_puppet.html#enhancements_puppet_x-7-8-0-pup-11076

and also, as was noted in #1009643 the puppet tests fail on 3.0 which 
seems to indicate that supporting puppet 5.5 in debian testing will be 
quite difficult.

Because of that information I think we should aim for removing puppet 5 
from testing and then move on to the discussion of packaging future 
versions.


that same argument about ruby 3.0 support would lead me to believe that 
aiming for puppet 6 would be a mistake (that and the EOL date for puppet 
6 which will be very close to a debian release).


in the #puppet channel on chat.libera.net, a couple poeple told me that 
since puppet 4.x the differences in terms of manifests are mostly 
additive and don't see many breakage at all between major versions, and 
that would be true until at least puppet 7. so it should be possible for 
users to jump from 5 to 7 directly

On Thu, 31 Mar 2022 11:24:34 -0400 =?utf-8?Q?Antoine_Beaupr=C3=A9?= 
<anarcat@debian.org> wrote:
> On 2022-03-31 17:05:19, Thomas Goirand wrote:
> > On 3/29/22 21:08, Antoine Beaupré wrote:
> >> On 2020-02-02 13:06:42, Thomas Goirand wrote:
> >> 
> >> [...]
> >> 
> >>> FYI, I packaged and uploaded the first 2 so far, but can't push to Git.
> >>> Please set me as maintainer or owner, so I can do that.
> >>>
> >>> Note that I'm doing a git based workflow, packaging upstream tags,
> >>> rather than using pristine-tar. If this bothers anyone, please let me
> >>> know (but please only complain about the workflow if you really have the
> >>> intention to contribute to the packaging, otherwise you're just getting
> >>> on my way to be efficient for no reason).
> >> 
> >> Not sure I'm picking the right message to reply to here, but here we go.
> >> 
> >> I see that you uploaded 6.16.0-1 to experimental back in December 2020:
> >> 
> >> https://tracker.debian.org/news/1205795/accepted-puppet-6160-1-source-into-experimental/
> >> 
> >> Is that package in any shape to ship with bookworm? It would be great to
> >> start this transition to get the package down into testing soon...
> >
> > Uploading it will break current puppet-master. Unless we have a solution 
> > to replace it, I don't want to do that...
> 
> I understand that, but my perspective is that we *want* to break the
> current, 5.5 puppet master. We do *not* want to ship that in
> bookworm. So breaking it is acceptable in that sense, to me.
> 
> But I guess it's pointless to keep arguing that same point. :)
> 
> -- 
> The survival of humans and other species on planet Earth in my view can
> only be guaranteed via a timely transition towards a stationary
> state, a world economy without growth.
>                          - Peter Custers
> 
> 

Message #100 received at 950182@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: pkg-puppet-devel@alioth-lists.debian.net

Cc: Thomas Goirand <zigo@debian.org>, 950182@bugs.debian.org, 830904@bugs.debian.org

Subject: Re: a proposal to salvage Puppet Debian packages

Date: Thu, 14 Apr 2022 10:23:26 -0400

On 2022-03-30 11:28:09, Antoine Beaupré wrote:
> Hi,

Following up on my own thread, two weeks later.

> TL:DR; (1) I want to join the team (2) let's package puppet agent 6
> clean, then puppetserver 6 and/or 7 for bookworm.

It seems I was granted access to the Puppet team on salsa, thanks! :)

And since then, I noticed some critical information that I hadn't
noticed before: Ruby 2.7 was removed from bookworm.

https://tracker.debian.org/news/1311269/ruby27-removed-from-testing/

This means that any Puppet version before Puppet 7.8 will likely not run
in Debian bookworm at all, since that's the first version which added
support for Ruby 3+:

https://puppet.com/docs/puppet/7/release_notes_puppet.html#release_notes_puppet_7-8-0

I still think my proposal makes sense. We should focus on upgrading the
client to Puppet agent 6, which should hopefully survive that transition
regardless. Then we could focus on packaging Puppet Server *seven*,
since it *will* be compatible with the Puppet agent 6. We would, in
effect, be skipping Puppet Server 6.

This has a few implications for our users. They will either need to:

 * upgrade everything at once, that is: upgrade the server from Puppet
   master 5 to Puppet server 7, and *simultaneously* upgrade from Puppet
   agent 5 to Puppet agent 6 (an alternative would be to setup a
   different Puppet server 7 and migrate machines over to that server
   progressively, but this could be messy with exported resources)

 * use the upstream packages for Puppet server 6 while the fleet is
   upgraded to Puppet agent 6, then switch back to the Debian package
   for Puppet server 7

I don't really see another way around this, because Puppet server 6
can't possibly work in Debian bookworm and above anymore, because of the
Ruby 2.7 removal.

The Puppet Server 7 work could happen in th Clojure team sprint in May,
which would land us a Puppet server ready for the bookworm freeze.

We *could* also work on Puppet server 6 and "fast track" it to bullseye:

https://fasttrack.debian.net/

But that feels like duplication of work a little. If I would have to
choose between Puppet server 6 and 7, I would choose the latter. And
given how much availability we all seem to have to work on this problem,
it *does* seem like we need to choose.

If there are no objections, I'll start working on the agent 6 in the
next few weeks/months.

Thanks for any feedback,

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

Message #105 received at 950182@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: Gabriel Filion <gabster@lelutin.ca>, 950182@bugs.debian.org, 950182@bugs.debian.org

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

Date: Thu, 14 Apr 2022 10:26:01 -0400

Control: severity -1 serious

Justification: this package depends on ruby 2.7, gone from bookworm. See
below.

On 2022-04-14 10:12:25, Gabriel Filion wrote:
> in current debian testing, ruby has been transitioned to 3.0 and judging 
> from the release history, puppet has not added support for ruby 3.0 
> until 7.8.0:
>
> https://puppet.com/docs/puppet/7/release_notes_puppet.html#enhancements_puppet_x-7-8-0-pup-11076
>
> and also, as was noted in #1009643 the puppet tests fail on 3.0 which 
> seems to indicate that supporting puppet 5.5 in debian testing will be 
> quite difficult.
>
> Because of that information I think we should aim for removing puppet 5 
> from testing and then move on to the discussion of packaging future 
> versions.
>
> that same argument about ruby 3.0 support would lead me to believe that 
> aiming for puppet 6 would be a mistake (that and the EOL date for puppet 
> 6 which will be very close to a debian release).

Agreed. Let's remove it for now. When we land a Puppet agent 7 here,
this bug can be closed and the package will migrate down to bookworm
again.

> in the #puppet channel on chat.libera.net, a couple poeple told me that 
> since puppet 4.x the differences in terms of manifests are mostly 
> additive and don't see many breakage at all between major versions, and 
> that would be true until at least puppet 7. so it should be possible for 
> users to jump from 5 to 7 directly

I proposed as much in the "policy" thread, so I think that would really
make a lot of sense. Worst case, this fails and we *also* need to
package Puppet server 6 in fasttrack.

Thanks for the heads up.

a.

-- 
Le péché est né avant la vertu, comme le moteur avant le frein.
                         - Jean-Paul Sartre

Message #124 received at 950182-done@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 610877-done@bugs.debian.org,670337-done@bugs.debian.org,693203-done@bugs.debian.org,723188-done@bugs.debian.org,809786-done@bugs.debian.org,869183-done@bugs.debian.org,879230-done@bugs.debian.org,894800-done@bugs.debian.org,927801-done@bugs.debian.org,928463-done@bugs.debian.org,950182-done@bugs.debian.org,950185-done@bugs.debian.org,983913-done@bugs.debian.org,984603-done@bugs.debian.org,987254-done@bugs.debian.org,987255-done@bugs.debian.org,989224-done@bugs.debian.org,1003867-done@bugs.debian.org,1006231-done@bugs.debian.org,1009643-done@bugs.debian.org,1009799-done@bugs.debian.org,1014772-done@bugs.debian.org,

Cc: puppet@packages.debian.org

Subject: Bug#1021202: Removed package(s) from unstable

Date: Tue, 04 Oct 2022 17:23:44 +0000

Version: 5.5.22-4+rm

Dear submitter,

as the package puppet has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/1021202

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Thorsten Alteholz (the ftpmaster behind the curtain)

Send a report that this bug log contains spam.