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

Send a report that this bug log contains spam.