search

basho-labs / puppet-riak

A puppet module to deploy Riak clusters
Apache License 2.0
33 stars 37 forks source link

puppet version requirements, platform requirements survey #51

Closed danieldreier closed 9 years ago

danieldreier commented 9 years ago

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

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 commented 9 years ago

@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 :smile: - others can add their favorites later.

Cornellio commented 9 years ago
danieldreier commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

I'm in support of:

:+1:

danieldreier commented 9 years ago

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:

Cornellio commented 9 years ago

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 commented 9 years ago

+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 commented 9 years ago

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 commented 9 years ago

No, I'm using CentOS.

danieldreier commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

:+1: