puppet4

[lbetz]

With version 2.0.0 we will kick puppet3 support. What version should be the lowest we support?

[dnsmichi]

I'd say the same as puppet-icingaweb2 v2, >= 4.7.0

[lbetz]

And the reasons?

…

Am 16.11.2017 um 09:27 schrieb Michael Friedrich ***@***.***>: I'd say the same as puppet-icingaweb2 v2, >= 4.7.0 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#402 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEDqLfJS1oatExm0vi4NtUlqXjhN8I6wks5s2_IEgaJpZM4Qf_sS>.

[dnsmichi]

Mainly keeping it the same with other puppet-* modules which are likely used in combination with this one.
I don't mind if you bump it to 4.10 being the latest and greatest. I do have a special use case for this module inside the Vagrant boxes, my opinion here counts less.

[lbetz]

I posted this question in forecast that you answers....:) My idea was version 4.9 and higher to use hiera 5 and replace params.pp with module data.

[dnsmichi]

Ok then ;)

• from a feature point of view, use the version which fits best for development and speed.
• upgrading 4.x is "easier" from a maintenance POV, since there's this AIO package, no OS specific dependencies and forecasts on upgrade anymore.
• same goes for 5.x, if you can make exceptions here too. 5.3 is current, might be worthwhile to not support 5.0 if it got missing features.

I cannot find a lifecycle information for Puppet 4 opensource, only for PE. Dunno when EOL will then be announced, this might happen in silence such as Puppet 3.

[rick-pri]

I posted this question in forecast that you answers....:) My idea was version 4.9 and higher to use hiera 5 and replace params.pp with module data.

I like this idea. However, you're going to need to update the examples I think; and I think that they really need some work.

I've spent the last 5 working days trying to understand the examples and to implement a working system in FreeBSD; I've only just managed to get a client and a master set up with a CA...and I'm getting a warning about the CA being self signed...which I'm hoping is just a warning and not breaking anything.

I cannot find a lifecycle information for Puppet 4 opensource,

I think that you'd have to work out what the end of life of the last platform which supported puppet agent 4 was and use that date where the newer platforms supported puppet agent 5 only. It's a really unclear lifecycle policy.

[baurmatt]

I think that you'd have to work out what the end of life of the last platform which supported puppet agent 4 was and use that date where the newer platforms supported puppet agent 5 only. It's a really unclear lifecycle policy.

I think you're referring to this document, right? I pretty sure that this document doesn't describe the EOL of a specific Puppet version, but more the support of Puppet in general for the platform. Because, if it would describe the EOL of a specific Puppet version, they need to support Puppet probably until 2025....

[dnsmichi]

Observation from standard Puppet modules in Icinga/icinga-vagrant#56 - they use >= 4.7.0 through out.

[lesinigo]

also: Puppet itself has removed online documentation for opensource versions lower than 4.6 and enterprise versions lower than 2016.4.x (which goes from Puppet 4.7 up to Puppet 4.10).

Puppet >= 4.7 is also what some widely used modules are currently requiring, such as puppetlabs/concat, puppetlabs/postgresql, puppetlabs/mysql and many others.

As @dnsmichi already said upgrading 4.x to another 4.y is rather easy, but there can be Enterprise users that have a slower upgrade cycle at least between different releases.

I don't see any reason not to upgrade any opensource 4.x to the latest 4.10.x and I also recommend any enterprise 2016.4.x to upgrade to the latest 2016.4.9, so if it was me I would target only puppet >= 4.10. But if you want to target people who don't upgrade at all I'd go with >= 4.7.
IMHO there really is no point in going lower than that for a new, not-yet-released, module version.

Also going Hiera5 (and thus adjusting the minimum requirements) would be a good thing for the module, especially looking at the future and Puppet 5 / 6 support and the most common usage scenarios with the 2.0.x generation of this module.

[lbetz]

We're going to support puppet v4.9 and higher with puppet-icinga2 v2.0.0

[dnsmichi]

Awesome, thank you 👍