On Apr 10, 2016, at 2:05 AM, Alex Harvey <[email protected]> wrote:
> I remember Nigel saying after Puppet 3 was released that Puppet would now > stabilise. That was in 2012, and yet here we are in 2016 and we have so many > deprecations coming that a dedicated deprecation log file to keep track of > them all seems like a good idea. Hey Alex. I'm not sure I can respond point-by-point to the conversation, but I did want to chime in because you raise a lot of valid points and deserve a response. I've been the product manager for Puppet for the four years you're talking about and thus bear at least partial responsibility for the changes in question. Thomas' mail earlier up-thread put this really succinctly: > For many people right now the configuration manager is the fastest moving > target in their tool stack. We're trying to navigate a tension between, on one side, the push from Puppet as a business and config management as a discipline to close competitive gaps and add functionality; versus the other side, from existing customers and the wider ecosystem to stabilise and change as little as possible (excepting of course the bugs that personally affect whomever you're speaking with at the moment). I'm definitely sympathetic to the viewpoint that the ripple effects since Puppet 4 landed last April have sacrificed the latter. Ironically, in order to cause fewer major-version bumps, we bundled three loci of change together that cumulatively make for a very large barrier to upgraders: - the language: as RI points out, people who kept current on the changes and deprecations through the 3.x series had a pretty minor lift to get to the Puppet 4.x language. But there's a perverse disincentive that I don't think we really anticipated, where the removals around node inheritance, import, and dynamic scope meant people who'd invested a lot in their Puppet infrastructure when those patterns were au courant in the 2.6 and 2.7 timeframe suddenly faced having to restructure a ton of code which had previously been working fine. You're absolutely right that unless there are substantive benefits for going through that effort, it's only rational for someone to look at non-Puppet solutions for the problem. - the packaging: looking back to the 2.6 and 2.7 era, the main way people obtained Puppet was through their distribution. Over time, Puppet's immediate dependencies widened to include things like hiera and the costs of supporting distribution-specific Ruby variants exploded, so we consolidated on the all-in-one packaging style and unified the agent side across OSS and PE. This has a ton of benefits (as someone who had to hand-build a patched Ruby to get a fix for the pthread thing <http://timetobleed.com/fix-a-bug-in-rubys-configurein-and-get-a-30-performance-boost/> I would appreciate someone else having done that for me) but means that people both have to change their adoption pattern and migrate existing hosts, which again has some cost. - the network stack: while it is possible to run a Puppet 4-based master under Passenger, it's not where our tech roadmap is taking us and we do not make it easy for people to do it themselves. This is probably where the clojure angst you were relaying came in; we've had clojure in our stack since 2012 and nobody got too worked up about it, perhaps because PuppetDB was both opt-in and self-contained. The puppet-server is neither of those things so, again, there's some cost that comes at a point in the stack that is a main point of interaction for people running puppet infrastructure. One cheerleading note on the benefits here: I would encourage people experiencing performance pinch on their masters to try out the latest versions, as our internal scale testing and reports from the field have shown pretty shockingly awesome compile time and concurrency improvements... > If I may, I think Puppet is taking far too much feedback from Puppet > enthusiasts (e.g. Puppet Test Pilots, speakers at conferences) and not enough > from all the people who don't bother filling in surveys, who don't go to > Puppet Camp, and are quietly as frustrated as all hell with Puppet. I'd love to hear suggestions for how to get feedback from people who won't talk to us through any of the channels they have available to them :-) Joking aside, the point is well taken. Until a couple of months ago we felt like the "organic" upgrade rate was pretty tolerable. But I definitely have a sense of urgency about not simply pushing as many people over the line as possible, but identifying and mitigating the causes of upgrade pain more generally. We're not going to stop the pace of change in the industry to let everyone catch up; there will be a Puppet 5 (and 6 and 7) at some point; but clearly we need to take care of people who are successful with Puppet today and make it easy for them to stay current without spending a ton of time managing their management infrastructure. Eric Sorenson - [email protected] <mailto:[email protected]> - freenode #puppet: eric0 puppet platform // coffee // techno // bicycles -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/FB8FE0E9-F138-40FA-A3AE-62C9081B546C%40puppet.com. For more options, visit https://groups.google.com/d/optout.
