Hi Eric! Am 10.04.2016 um 21:16 schrieb Eric Sorenson: > On Apr 10, 2016, at 2:05 AM, Alex Harvey <[email protected] > <mailto:[email protected]>> wrote: > > [...] 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 [...] we bundled three loci of change together that > cumulatively make for a very large barrier to upgraders: > > - the language: [...]
While I definitively know that they are still there, less and less people (at least those who I met and know) are running 0.2x or 2.x. They invested a lot of time and are happy 3.x users right now. And realized, that they are on an old version once again. And you nailed it, the language alone is not the problem at all. Puppet 4 has a lot of new features, but for a migration you do not even have to learn about most of them. Still, there are small differences that could hurt. They are well explained, but they are not always easy to find in your modules. The bigger problem to many is that basically the whole stack changed. For many, Puppet was the reason to learn Ruby. I personally loved it to teach the "Extending Puppet using Ruby" classes, even if we didn't sell many of them. They would still be requested, by the way ;) I stopped doing trainings once that class got discontinued. But let's get back on topic. They invested time, learned something new, and right Puppet started to do what they want. And they learn that Puppet would prefer to fade out the language they learned only to get more out of Puppet. We all know, this won't happen very soon - but that's the message they got. And they feel a little bit lost, as there might arrive something new, but it is still very unclear what that might look like. Just wanted to mention this, because this also somehow makes part of the "language". So, move to the new "Java/Clojure" stack? Loosing all the insights you have right now? While knowing that more changes are around the corner? Many might decide to wait a little bit longer. > - the packaging: [...] You might underestimate this, this is a big problem. IMO that's even more a problem than the whole Java/Clojure thing. First, to many people running Open Source puppet this feels like a lock in. If you try to run at least parts of the server stack separate, you have a lot of fun. And while Puppet is doing a very good job in shipping (security) upgrades all this feels not natural to many Linux admins. OpenSSL, Ruby, Java, all this from a single vendor in a separate directory? What if there is heartbleed, you must immediately upgrade but for whatever reason your Puppet is some versions behind? I immediately believe you that you also would care about those older versions. But that's a matter of trust. Puppetlabs OSS package repositories tend to be deprecated early, why should someone not running PE put any trust in whether all this would work for him with OSS AIO in a heartbleed-like scenario? Everybody understands it when you say "The Puppet master needs at least PostgreSQL 9.1 and Ruby 1.9.3", just to pick some fictional numbers. Supporting the Ruby agent on distros running Ruby 1.8.7 and OpenSSL 0.9.x for sure makes no fun, but it would have absolutely been possible, wouldn't it? Replacing it with the C++ one once available. AIO is definitively one of the reasons many people fear Puppet 4. I personally could live with git clone'ing Puppet Agent and Master, that's more then half the way to get it installed. But I guess that wouldn't convince many :D > - 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. And many do not see what should be so wrong with running a Ruby-based master under Passenger, Unicorn or whatever. > 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. That's right, PuppetDB has always been seen as a separate component. Often running on dedicated servers, upgraded separately. Usually nobody but the Puppet master needs to directly talk to it, so in case there is a security issue with any of it's dependencies and you fear a fast upgrade you can still lock it down with some firewall rules. > 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. And when there is some cost people tend to ask for the benefits... > 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... All this is pretty cool, and while initial Puppet Server versions performed badly I immediately believe you that this changed a lot. But hey, where is the benefit for those happily running a Puppet master without performance issues? And not worrying if they have such as they know how to scale it? PuppetDB is hard to scale, but adding compile masters has never been an issue, at least not since a very long time. I've seen Foreman breaking under reporting bursts while a single PuppetDB 1.6(!) instance serving 3 compile masters kept happily running. So, again: where is the benefit with all this for a Puppet setup serving several hundred to a few thousand nodes? Those with tens of thousands of nodes will not ask that question I guess. And those with that many containers probably to not install Puppet AIO in all of them. > 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 :-) Once you found them, give them some alcohol and listen - this usually helps ;) Yet, finding them could be tricky :p > 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. I'm not to be found on Facebook or Twitter or anything similar, but I would immediately like and retweet this many many times ;-) Thanks a lot for listening! Cheers, Thomas -- 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/neelsa%24aa8%241%40ger.gmane.org. For more options, visit https://groups.google.com/d/optout.
