puppet version requirements, platform requirements survey

[danieldreier]

How recent of puppet versions people using, and on what platforms? Specifically:

• How would people feel about using future parser / puppet 4 DSL?
• Puppet version since 3.4.0 have supported contain rather than the anchor pattern
• Can we require structured facts to be enabled?
• Am I the only person who wants FreeBSD support?
• What Linux distros do we need to support, and what major versions? I'm hoping EL 5 isn't on the list.

I'd personally love to just do development in future parser with puppet 3.7, but I realize that option isn't available to everybody, and that documentation on what future parser can do is extremely lacking.

[mbbroberg]

@danieldreier I'd be happy with support for CentOs & Ubuntu as a minimum. All supported OSes are listed here: http://docs.basho.com/riak/latest/downloads/

And there are a lot of them. It's okay to be selfish and want FreeBSD 😄 - others can add their favorites later.

[Cornellio]

• We still use PE 2.7
• Mixed feelings about using future parser / puppet 4 DSL. I would use it, but it might be too fast for mass consumption.
• We only use EL 6

[danieldreier]

Puppet 2.7 has been totally EOL'd since September 2014, so I certainly don't want to get in the business of supporting it. I'm assuming that when you migrate off of PE 2.7 you'll be moving onto the latest PE, which is PE 3.8 as of this morning.

I agree that there will likely be a hard time getting people to use puppet 4 DSL before puppet 4 comes out; I at least want to make sure that all of our code is future-compatible so it works on puppet 4 at all.

Puppet 4 also brings really nice things like type safety and iteration, so the code quality is potentially just enormously better.

At the very least I think we shouldn't support anything older than puppet 3.4, because before that you have to use the anchor pattern.

I'm aware that it'll limit the scope of who can use it, but the whole module ecosystem is about to go through a huge shift to get on the puppet 4 DSL and everybody still on older versions will have to invest some time into updating codebases at that point.

[Cornellio]

That sounds totally reasonable. I have no desire to support 2.7 either, just giving you an idea of what version we are using. Yes I plan to move directly to the latest version and expect having to refactor many of our modules.

Puppet 4 sounds like it'll be very nice.

On Mar 26, 2015, at 4:44 PM, Daniel Dreier notifications@github.com wrote:

Puppet 2.7 has been totally EOL'd since September 2014, so I certainly don't want to get in the business of supporting it. I'm assuming that when you migrate off of PE 2.7 you'll be moving onto the latest PE, which is PE 3.8 as of this morning.

I agree that there will likely be a hard time getting people to use puppet 4 DSL before puppet 4 comes out; I at least want to make sure that all of our code is future-compatible so it works on puppet 4 at all.

Puppet 4 also brings really nice things like type safety and iteration, so the code quality is potentially just enormously better.

At the very least I think we shouldn't support anything older than puppet 3.4, because before that you have to use the anchor pattern.

I'm aware that it'll limit the scope of who can use it, but the whole module ecosystem is about to go through a huge shift to get on the puppet 4 DSL and everybody still on older versions will have to invest some time into updating codebases at that point.

—
Reply to this email directly or view it on GitHub.

[mbbroberg]

@danieldreier what are your thoughts on answering the original questions?

I'm in support of:

• Latest Riak
• Latest Puppet
• CentOS, Ubuntu
• Require structured facts
• No opinion on parser

👍

[danieldreier]

Debian is the only platform I actually use in production, so that's the primary development target for everything I write. Ubuntu stuff almost always works if the upstream Debian version works, so adding Ubuntu support should basically be a matter of adding beaker / rspec-puppet test coverage.

CentOS will be a second-class citizen if I'm the only person writing test coverage for it, but the riak2 module I've been working on does have equivalent coverage for EL and Debian so far.

It sounds like @Cornellio will work on CentOS support, and I'll work on Debian support, but I'm not sure who (of project maintainers) has an actual stake in Ubuntu support.

I'd propose:

Latest Debian (currently Wheezy) and previous for ~1 year
CentOS 6 and 7, since both are widely used

I understand that there's a demand for Ubuntu support, but my experience is that simply asserting support coverage is inadequate when there's nobody in the project who actually cares a whole lot. That said, I don't feel terribly strongly about it - if we list Ubuntu 12.04 and 14.04 and have some token level of testing we can remove it down the road if it becomes unsupportable, or improve it as more contributors participate.

If nobody's actually opposed, let's make this a future-parser-only module requiring Puppet 3.7 or better. If we get it released relatively quickly, I think we might be able to make it the very first (nominally) Puppet 4 module, period. I'm willing to write it in current parser but am hesitant to pre-emptively compromise when everybody here seems fine with a future-parser-only one and I'd rather work in that. It probably means that we won't get hardly any users for the next few months, but it'll also provide more opportunities for publicity and greater functionality down the road.

To summarize:

• Latest Riak
• Latest Puppet
• CentOS, Debian
• Require structured facts
• Puppet 3.7 w/ future parser / Puppet 4

[Cornellio]

I accept those plans. I just use CentOS and RHEL in production so I can focus on that.

Let's attempt nominal support for Ubuntu as you say, as it's in common use and should follow smoothly from Debian.

[mbbroberg]

+1 as well @danieldreier. If we don't have someone who's passionate about Ubuntu, then passing on it is fair. @haf - do you have a stake in Ubuntu support?

[CompareGroup]

Just my 2 cents here.
We're on 3.7 CE and run everything on CentOS. We're putting in some major time to rework puppet code because of all the deprecations and changes so we can soon make the jump to puppet 4 when it becomes available. Because the future parser is only available in more recent version of puppet, and is the default parser (the only one?) in puppet 4, many puppet users may need to put in such time soon if they want to upgrade. I'm assuming that requiring the future parser will make it very hard for many existing puppet users to use the module. I'm also assuming that many larger users and maybe corporations won't make the change to the future parser for a long time, in order for bugs to get worked out before doing the major re-work that upgrading would involve. Would that be a reasonable assumption? In that case requiring the future parser may be too early?
I'm also assuming we can write the module in such a way that it's usable with both old and new versions, as long as we don't use any of the new features from the future parser. Once the major puppet userbase has switched to the future parser we could improve those parts of the code that need it most.

+1 on structured facts and puppet >3.4 because of contain

[haf]

No, I'm using CentOS.

[danieldreier]

@CompareGroup thanks for providing some input. I agree that there will be people who can't use this due to the future parser. There's an upcoming version of puppet coming out that will allow enabling and disabling future parser on a per-environment basis using directory environments, so that should help to some extent.

If this was an existing Riak 2 module and we were discussing breaking backwards compatibility, I'd 100% say stick with current parser. Since there is no user base at all on this module, I feel like it's acceptable if we don't get many users for a while.

Even using future parser, we actually are maintaining more backwards compatibility than if it was a pure puppet 4 module -- puppet 4 has support for a data-in-modules pattern that replaces the params.pp approach, for example, but it's entirely backwards-incompatible so I used params.pp. We'll probably be having this conversation again somewhere down the road to drop 3.x support entirely, but I imagine that'll be a while.

[danieldreier]

I think we can close this - we've got a release, some clarity on what people are hoping to use, and we can re-open if necessary as people run into issues or want to make improvements.

[mbbroberg]

👍