search

voxpupuli / plumbing

Utilities for Vox Pupuli management
2 stars 34 forks source link

RFC: Support Puppet 4 only #21

Closed daenney closed 7 years ago

daenney commented 8 years ago

RFC: Support Puppet 4 only

This is going to be a bit controversial because I'm raising it this early. This is not a proposal to move to Puppet 4 only now now now. Instead it is meant for us to find a good way on how to move to Puppet 4 and define some metrics at which point we deem it acceptable to move to a Puppet 4 only version of our modules.

Reasons for moving to Puppet 4

Puppet 4 brings a vast number of improvements but besides the runtime speedup it's mostly language features and sanitisation that we, the developers, can benefit from allowing us to write more concise, bug-free, testable and compact manifests. This in turn raises the quality of our modules which is good for everyone that uses them. Some of the features deemed most important:

Additionally a new way to deal with data in modules is starting to emerge in Puppet 4 that in due time we'll be able to take advantage of too (though perhaps not before Puppet 5 depending on when the feature is deemed finalised).

Collecting data

The most important thing to do in order to decide when the time is right is to collect as much data as we can on Puppet 4 deployments and their ratio to Puppet 3.

Data that could help us make this decision:

The problem with all of this is once we move to Puppet 4 only the code will simply not work anymore on older versions of Puppet, most notably Puppet 3 which is still widely deployed. Though Puppet 4 has been out for a year now and multiple community members are holding talks at PuppetConf, Puppet Camp's and Configuration Management Camp on how to migrate to Puppet 4 and what new features it brings adoption is still slow. Puppet Labs has successfully been pushing Puppet 4 through PE upgrades.

As such we need to define a threshold at which point, based on the data that we decide to collect, we believe the time is right to move to Puppet 4. However, when we do decide to do so we should still provide critical bug fix releases for Puppet 3 compatible versions of our modules for a number of months to not unnecessarily complicate other people's lives.

Therefor I would propose a transition somewhere along these lines:

The one question that remains: how do we decide it is time?

List of tasks / bugs that we need to do/fix prior to being able to move

daenney commented 8 years ago

I would suggest we keep your timeline with regards to adding the warnings etc. but only flip the bit in February so that everyone's had some time to catch their breath after new year.

rnelson0 commented 8 years ago

Revised proposal (in the one true date format):

juniorsysadmin commented 8 years ago

@rnelson0 Consider moving the end date forward from 20170430 to 20170331 perhaps, otherwise sounds good to me.

mmckinst commented 8 years ago

I created a couple puppet linters to migrate facts to a newer style for puppet 4

daenney commented 8 years ago

@mmckinst Nice! If they're not on our site yet, would you mind submitting a PR against voxpupuli/voxpupuli.github.io, w.r.t to https://github.com/voxpupuli/voxpupuli.github.io#puppet-plugins? Essentially updating this file https://github.com/voxpupuli/voxpupuli.github.io/blob/master/_data/tools/puppet-lint.json with your linters.

rnelson0 commented 7 years ago

I've engaged the PMC now that we have one to get the announcement out!

@juniorsysadmin I specified April so there was a 90 day window between deprecation and end of support. Do you think 60 days is sufficient? (sorry I missed the comment back in August)

juniorsysadmin commented 7 years ago

Do you think 60 days is sufficient?

Yes

bastelfreak commented 7 years ago

Good evening everybody. The PMC has created a proposal for the Puppet 4 deprecation. We would like to discuss the following with you and make a decision in the next days via lazy consensus.

Deprecation of Puppet 3

The End of Puppet 3

Puppet 3 will be End of Life 2016-12-31. We see Vox Pupuli as a vendor of many software products. As a vendor we are responsible for the security of our users and should not encourage them to use outdated or end-of-life software. Therefor we will start to deprecate Puppet3 at 2017-01-01.

Timeline

rnelson0 commented 7 years ago

I think we previously noted that we don't want to force people to come back from a holiday vacation and have to deal with upgrading the world right away. If we could give people at least 15-30 days before we start the new, puppet3-less releases, it may make for a better user experience.

Otherwise I do like the accelerated timelines if we get consensus.

nibalizer commented 7 years ago

Whoa I don't think adding a warn() function to every module is in any way polite. Someone could easily get a dozen or more warnings every puppet run.

nibalizer commented 7 years ago

To me, it seems like we only need to do one thing on 2017-01-01:

Write a blog post that says "Puppet 3 is dead, the Puppet 4 floodgates are open, write whatever you want!"

Then whenever a module gets puppet4 only code, the next release of it bumps the major version. At the same time the puppet4 code is about to merge, a 'puppet3' branch should be created, in case anyone needs the last functional puppet3 code.

I don't think we need to release every module just to add warnings. I don't think we need to drop puppet3 from metadata.json unless puppet4 code was added.

Cinderhaze commented 7 years ago

@nibalizer - would adding a suppress_puppet3_deprecation_warning parameter that defaults to false on all modules be more polite? That would enable a consistent way via hiera's APL to disable the warnings?

hlindberg commented 7 years ago

On 05 Nov 2016, at 09:35, Spencer Krum notifications@github.com wrote:

Whoa I don't think adding a warn() function to every module is in any way polite. Someone could easily get a dozen or more warnings every puppet run.

There is a “warn_once” option for puppet deprecations that uses a symbol/string for the uniquness. Thus, if all vox populi modules uses the same warn_once symbol it is only shown once.

DavidS commented 7 years ago

@nibalizer that's the way I chose to do the puppet3 deprecation for the NTP example module: 4.2.0 was the last release to support puppet 3, with the change to ntp v5.0 we "silently" dropped puppet 3 support and started using puppet 4 features.

After puppet 3, the deprecation() function does "warn once" functionality where the developer can limit the amount of messages, and configuration settings for the user to suppress the messages. This is what we'll be using going forward from now, together with the validate_legacy() function to step up to data types.

Long-term my goal is that any "last" release of a module in a major series (like the NTP v5.0.0 above) will provide a configuration that a) does not cause deprecation warnings and b) will work unmodified in the major+1 version (like the NTP v6.0.0 release). This should avoid the pain we had with e.g. apt, allow folks to discover the changes they need to make to their config, and update on their own pace.

nibalizer commented 7 years ago

@Cinderhaze @hlindberg I don't think we need the deprecation warnings. I get warnings from software all the time that I can do nothing about. Who is this deprecation message for? Someone who is running puppet3 but plugged in enough to the outside world to update to latest of a voxpupuli module? That person should already know that puppet3 is EOL and doesn't need us warning them every time they run puppet.

It is not a module's job to scold you for running an old puppet, I think.

nibalizer commented 7 years ago

@DavidS exactly.

That can happen at a different time for every module. Or someone can go wild and do it to all the modules in the span of a couple weeks. But I think doing the other 4 steps without having puppet 4 code to merge in is just busywork.

rnelson0 commented 7 years ago

FWIW I read "We will add a warning" as adding a note to the readme in a published version. I definitely do not like the idea of a warning function adding output to runs.

roidelapluie commented 7 years ago

@DavidS What we do with puppet-corosync is we have a LTS version we will support until Puppet 3 vox pupuli depreciation, and newer versions which use puppet 4 features

DavidS commented 7 years ago

@roidelapluie technically the last puppet3 compatible ntp version is commercially supported by us, and I would expect to do hotfix releases for security issues, and other critical breakage, but e.g. no new platforms (puppet 3 wouldn't support them anyways), or new features (backporting is rewriting).

nibalizer commented 7 years ago

https://voxpupuli.org/blog/2016/12/22/putting-down-puppet-3/ I ended up writing that and @bbriggs merged it.

In hindsight, we should have put a nice 'need decision by X' on this so that we'd have our plan in place and people could plan around it.