Topics

Get rid of Puppet4?

 

Hi everybody,

Puppet 5 is available since a long time. Besides many bug fixes it also
has support for hiera 5 configs as data-in-modules. Some time ago in the
IRC channel we agreed on Puppet 4.7.1 as our lowest supported Puppet
version and at least Stdlib 4.13.1. A few of our modules ship
data-in-modules with hiera 5. This got introduced in Puppet 4.8(?) but
had some bugs. The agreement, and recommendation by Puppet, was to
require at least Puppet 4.10.X in those cases.

I would like to get feedback from the community here. Do you think it is
still needed to support puppet 4 at all? Is 4.10 even to high as the
lowest version?

My point of view is that upgrades, since the AIO packages are available,
are really easy and everybody should be able to regularly update their
nodes. Dropping Puppet 4 would allow us to reduce the test matrix and
speed CI runs up. Also we would be safe with data-in-modules/hiera5. We
also need to keep in mind that not everybody is required to update their
used modules to the latest version, just because they are available.

The trigger for this was
https://github.com/camptocamp/puppet-systemd/pull/73. What are your
opinions on this topic?

Cheers, Tim

Thomas Mueller <thomas@...>
 

On 03/21/2018 09:50 AM, Tim Meusel wrote:
Hi everybody,

Puppet 5 is available since a long time. Besides many bug fixes it also
has support for hiera 5 configs as data-in-modules. Some time ago in the
IRC channel we agreed on Puppet 4.7.1 as our lowest supported Puppet
version and at least Stdlib 4.13.1. A few of our modules ship
data-in-modules with hiera 5. This got introduced in Puppet 4.8(?) but
had some bugs. The agreement, and recommendation by Puppet, was to
require at least Puppet 4.10.X in those cases.
Voxpupuli should generally support puppet versions supported by Puppet Inc.

Lifecycle: https://puppet.com/misc/puppet-enterprise-lifecycle
Oldest supported PE release: 2016.04
Component list: https://puppet.com/docs/pe/2016.4/overview_version_table.html

Oldest supported Puppet version: 4.10.x

But I don't think you can create a policy that fits for every voxpupuli module. For some modules it maybe makes sense to support older puppet and for others not.

- Thomas

Ewoud Kohl van Wijngaarden
 

On Wed, Mar 21, 2018 at 09:58:20AM +0100, Thomas Mueller wrote:
On 03/21/2018 09:50 AM, Tim Meusel wrote:
Hi everybody,

Puppet 5 is available since a long time. Besides many bug fixes it also
has support for hiera 5 configs as data-in-modules. Some time ago in the
IRC channel we agreed on Puppet 4.7.1 as our lowest supported Puppet
version and at least Stdlib 4.13.1. A few of our modules ship
data-in-modules with hiera 5. This got introduced in Puppet 4.8(?) but
had some bugs. The agreement, and recommendation by Puppet, was to
require at least Puppet 4.10.X in those cases.
Voxpupuli should generally support puppet versions supported by Puppet Inc.

Lifecycle: https://puppet.com/misc/puppet-enterprise-lifecycle
Oldest supported PE release: 2016.04
Component list: https://puppet.com/docs/pe/2016.4/overview_version_table.html

Oldest supported Puppet version: 4.10.x
Satellite 6.3 just came out and it includes Puppet 4.10.9 so I'd be happy if we continued to support it. Dropping anything older would be fine by me. I think that aligns with the PE versions.

But I don't think you can create a policy that fits for every voxpupuli module. For some modules it maybe makes sense to support older puppet and for others not.
Even if it's not a policy, some guidelines are good to have.

 

On 03/21/2018 10:39 AM, Ewoud Kohl van Wijngaarden wrote:
On Wed, Mar 21, 2018 at 09:58:20AM +0100, Thomas Mueller wrote:
On 03/21/2018 09:50 AM, Tim Meusel wrote:
Hi everybody,

Puppet 5 is available since a long time. Besides many bug fixes it also
has support for hiera 5 configs as data-in-modules. Some time ago in the
IRC channel we agreed on Puppet 4.7.1 as our lowest supported Puppet
version and at least Stdlib 4.13.1. A few of our modules ship
data-in-modules with hiera 5. This got introduced in Puppet 4.8(?) but
had some bugs. The agreement, and recommendation by Puppet, was to
require at least Puppet 4.10.X in those cases.
Voxpupuli should generally support puppet versions supported by Puppet
Inc.

Lifecycle: https://puppet.com/misc/puppet-enterprise-lifecycle
Oldest supported PE release: 2016.04
Component list:
https://puppet.com/docs/pe/2016.4/overview_version_table.html

Oldest supported Puppet version: 4.10.x
Satellite 6.3 just came out and it includes Puppet 4.10.9 so I'd be
happy if we continued to support it. Dropping anything older would be
fine by me. I think that aligns with the PE versions.
I agree. I'm fine with supporting 4.10.X until it's EOL (october?). But
we should not support anything that's EOL. As a module author we act as
a software "vendor" to or users, we're responsible for them. We should
not encourage them to run outdated software. We should also point out
that people are not required to update their local module version, just
because we released a newer version.

I wrote that many times in issues and pull requests. I just realized
that our Puppet 4.7.1 is now EOL as well and we should maybe bump the
puppet version in all modules to at least 4.10.X? No matter if they use
data-in-modules or not.

But I don't think you can create a policy that fits for every
voxpupuli module. For some modules it maybe makes sense to support
older puppet and for others not.
Even if it's not a policy, some guidelines are good to have.


David Hollinger
 

I'm with Thomas on this, we should always have the same support matrix as Puppet, Inc.
Many of our users will be relying on their support lifecycle and for us to stay relevant within Puppet world,
we need to ensure that we don't make it too hard for users to utilize our tools.

While it does appear that 4.7.1 would be EOL based on the patch releases for PE 2016.4, the support lifecycle
lists the minor release as the supported version. I almost think we need some feedback from Hunner and Eputnam
before we make any decisions.

Regardless, I'm strongly against dropping support for any version that Puppet, Inc still provides support for.

James Powis
 

I have mixed feelings on this, Just back in January I migrated a Client from 3.6 to 5 ... On one hand support can be maintained at a cost to the maintainers, mean while pinning versions and revving major versions is perfectly acceptable in my book... I have now worked at 3 different shops using puppet to varying degrees of success, but every one of them have pinned version of the external modules they were using (after learning the hard way first). 

At a bare minimum, mirroring the PE LTS EOL dates would be recommended.

Thanks,

James R. Powis



On Wed, Mar 21, 2018 at 2:50 AM, Tim Meusel <tim@...> wrote:
Hi everybody,

Puppet 5 is available since a long time. Besides many bug fixes it also
has support for hiera 5 configs as data-in-modules. Some time ago in the
IRC channel we agreed on Puppet 4.7.1 as our lowest supported Puppet
version and at least Stdlib 4.13.1. A few of our modules ship
data-in-modules with hiera 5. This got introduced in Puppet 4.8(?) but
had some bugs. The agreement, and recommendation by Puppet, was to
require at least Puppet 4.10.X in those cases.

I would like to get feedback from the community here. Do you think it is
still needed to support puppet 4 at all? Is 4.10 even to high as the
lowest version?

My point of view is that upgrades, since the AIO packages are available,
are really easy and everybody should be able to regularly update their
nodes. Dropping Puppet 4 would allow us to reduce the test matrix and
speed CI runs up. Also we would be safe with data-in-modules/hiera5. We
also need to keep in mind that not everybody is required to update their
used modules to the latest version, just because they are available.

The trigger for this was
https://github.com/camptocamp/puppet-systemd/pull/73. What are your
opinions on this topic?

Cheers, Tim





Eric Sorenson <eric@...>
 

Hi all, good to see this thread - I put some comments inline.

On Mar 21, 2018, at 2:45 AM, Tim Meusel <@bastelfreak> wrote:
On 03/21/2018 10:39 AM, Ewoud Kohl van Wijngaarden wrote:
On Wed, Mar 21, 2018 at 09:58:20AM +0100, Thomas Mueller wrote:
On 03/21/2018 09:50 AM, Tim Meusel wrote:
Hi everybody,

Puppet 5 is available since a long time. Besides many bug fixes it also
has support for hiera 5 configs as data-in-modules. Some time ago in the
IRC channel we agreed on Puppet 4.7.1 as our lowest supported Puppet
version and at least Stdlib 4.13.1. A few of our modules ship
data-in-modules with hiera 5. This got introduced in Puppet 4.8(?) but
had some bugs. The agreement, and recommendation by Puppet, was to
require at least Puppet 4.10.X in those cases.
Voxpupuli should generally support puppet versions supported by Puppet
Inc.

Lifecycle: https://puppet.com/misc/puppet-enterprise-lifecycle
Oldest supported PE release: 2016.04
Component list:
https://puppet.com/docs/pe/2016.4/overview_version_table.html

Oldest supported Puppet version: 4.10.x
Satellite 6.3 just came out and it includes Puppet 4.10.9 so I'd be
happy if we continued to support it. Dropping anything older would be
fine by me. I think that aligns with the PE versions.
I agree. I'm fine with supporting 4.10.X until it's EOL (october?). But
we should not support anything that's EOL. As a module author we act as
a software "vendor" to or users, we're responsible for them. We should
not encourage them to run outdated software. We should also point out
that people are not required to update their local module version, just
because we released a newer version.

I wrote that many times in issues and pull requests. I just realized
that our Puppet 4.7.1 is now EOL as well and we should maybe bump the
puppet version in all modules to at least 4.10.X? No matter if they use
data-in-modules or not.
Yeah I think >=4.10.x is a good target - there aren't any earlier 4.x series releases that are getting patches, since 4.10.x is the 'last of the line' before 5. It is a very short step from 4.10.x to 5 too, so i'd suggest being generous about dropping 4.x compatibility unless you *know* a module uses some 5.x-only construct.

This is in no way an official Puppet Inc statement but I suspect there will be a longer tail to 4.10 than just October 2018, given its inclusion in Satellite and widespread use out in the world.


But I don't think you can create a policy that fits for every
voxpupuli module. For some modules it maybe makes sense to support
older puppet and for others not.
Even if it's not a policy, some guidelines are good to have.
Does it work to make a new major version of the module that has tighter compatibility constraints? I think we talked about this as a community in the 3.x->4.x timeframe but I'm not sure how it's played out in reality. Do most downstream users pin versions to avoid breakage?

--eric0

 

On 21.03.2018 19:32, Eric Sorenson wrote:
Hi all, good to see this thread - I put some comments inline.

On Mar 21, 2018, at 2:45 AM, Tim Meusel <@bastelfreak> wrote:
On 03/21/2018 10:39 AM, Ewoud Kohl van Wijngaarden wrote:
On Wed, Mar 21, 2018 at 09:58:20AM +0100, Thomas Mueller wrote:
On 03/21/2018 09:50 AM, Tim Meusel wrote:
Hi everybody,

Puppet 5 is available since a long time. Besides many bug fixes it also
has support for hiera 5 configs as data-in-modules. Some time ago in the
IRC channel we agreed on Puppet 4.7.1 as our lowest supported Puppet
version and at least Stdlib 4.13.1. A few of our modules ship
data-in-modules with hiera 5. This got introduced in Puppet 4.8(?) but
had some bugs. The agreement, and recommendation by Puppet, was to
require at least Puppet 4.10.X in those cases.
Voxpupuli should generally support puppet versions supported by Puppet
Inc.

Lifecycle: https://puppet.com/misc/puppet-enterprise-lifecycle
Oldest supported PE release: 2016.04
Component list:
https://puppet.com/docs/pe/2016.4/overview_version_table.html

Oldest supported Puppet version: 4.10.x
Satellite 6.3 just came out and it includes Puppet 4.10.9 so I'd be
happy if we continued to support it. Dropping anything older would be
fine by me. I think that aligns with the PE versions.
I agree. I'm fine with supporting 4.10.X until it's EOL (october?). But
we should not support anything that's EOL. As a module author we act as
a software "vendor" to or users, we're responsible for them. We should
not encourage them to run outdated software. We should also point out
that people are not required to update their local module version, just
because we released a newer version.

I wrote that many times in issues and pull requests. I just realized
that our Puppet 4.7.1 is now EOL as well and we should maybe bump the
puppet version in all modules to at least 4.10.X? No matter if they use
data-in-modules or not.
Yeah I think >=4.10.x is a good target - there aren't any earlier 4.x series releases that are getting patches, since 4.10.x is the 'last of the line' before 5. It is a very short step from 4.10.x to 5 too, so i'd suggest being generous about dropping 4.x compatibility unless you *know* a module uses some 5.x-only construct.
sounds good

This is in no way an official Puppet Inc statement but I suspect there will be a longer tail to 4.10 than just October 2018, given its inclusion in Satellite and widespread use out in the world.


But I don't think you can create a policy that fits for every
voxpupuli module. For some modules it maybe makes sense to support
older puppet and for others not.
Even if it's not a policy, some guidelines are good to have.
Does it work to make a new major version of the module that has tighter compatibility constraints? I think we talked about this as a community in the 3.x->4.x timeframe but I'm not sure how it's played out in reality. Do most downstream users pin versions to avoid breakage?
We made that, in my opinion with quite a success, for the migration from
3.X to 4.7.1. We had some discussions about minor updates of a
dependency (mostly stdlib and/or puppet). Does that require a major
update of the module? In rare cases we said yes, in most cases no. The
general feedback for the Puppet 3-4 migration was good. Only a few users
complaint that the latest release isn't compatible with their puppet3
env. They didn't check the CHANGELOG.md properly. For most of those
releases we did a minor one to announce that the upcoming major one
doesn't work with Puppet 3 anymore.

--eric0




David Hollinger
 

Yeah I think >=4.10.x is a good target - there aren't any earlier 4.x series releases that are getting patches, since 4.10.x is the 'last of the line' before 5. It is a very short step from 4.10.x to 5 too, so i'd suggest being generous about dropping 4.x compatibility unless you *know* a module uses some 5.x-only construct.

This is in no way an official Puppet Inc statement but I suspect there will be a longer tail to 4.10 than just October 2018, given its inclusion in Satellite and widespread use out in the world.
Thanks for the input, Eric. With this I think we can justify reducing our support range down to >= 4.10.

--dhollinger