On Apr 12, 2016, at 10:54 AM, Dean Wilson <dean.wil...@gmail.com> wrote: > > On 11 April 2016 at 12:08, R.I.Pienaar <r...@devco.net> wrote: > >> Eric asked so here it is, this is my feedback with a open source user hat >> on. Echoing much what was said. I hope others send in their story. > > Since you asked so politely. > > I have a few main areas of concern, and oddly they are not so much > with the core puppet project. I think most of the work going in to it > is solid and makes the product more durable and offers a certain > amount of extra sophistication with things like the type system.
Glad to hear this, thank you. > So, my issues: > > AWS: Over the last 5 years I've deployed a -lot- of AWS and spoke to a > lot of people about it and unless they are a large enterprise > forklifting their current environment over or looking to run a few > bits of code at instance time, and just happen to have admins who > already know it, puppet doesn't really enter the equation. I remember > evaluating Puppet support for AWS resources about 4 years ago, finding > it in a very nascent state and then checking in every 6 months or so > and discovering that it's essentially not moved. To ignore such a > large player and platform these days is a massive negative to a lot of > potential users. > > A lot of places went with Ansible for this use case and even though > it's not an area puppet can be said to compete in its led to places > dropping the bits of puppet they did use and running local only > ansible on instances at create time. After all why run two config > management tools? In the same time frame Terraform has appeared and is > currently eating the cloud provisioning world. And what's annoying is > that if you use it for a few days it feels so very much like puppet > 0.25 did. Its sharing mechanisms are amazingly basic, it lacks a hiera > stand-in and it has no support for any composite data types. It's a > massive dose of deja-vu and it's something that puppet should be able > to compete with. I also think that in terms of language complexity > people flocking to Ansible and similar should be something to > consider, while I love puppet types, when I can use them without > losing puppet 3 support, a lot of people are happier writing YAML with > Jinja2 embeddd in it. And that's a little sad. We have always taken this area seriously, but it’s also never been our core use case. One of the biggest challenges in our business is finding the balance between helping people with the infrastructure of today but also helping them adopt the tech of tomorrow. We’ve taken multiple cracks at this stuff (remember cloud-provisioner?) but none of them have really worked out. I think the work Gareth is leading in this area is a real winner, though, so I think we’re on the right path now. Obviously we would all do things differently in retrospect, but in truth, I wouldn’t change how I balanced our efforts looking backward. I couldn’t have sold much software in that space over the last few years, so it was correct for us to focus more on people’s production infrastructure. Now that all of our customers are asking how they manage both AWS and on-premise, it’s become critical. And, of course, it’s worth noting that no one needs our permission to build great tools in this space. Gareth’s work is based on the work he did as a community member, and is just further developed as an employee of Puppet. If it was that important to all of you, you wouldn’t have waited for someone else to build it. So in the end, I would love to have been able to afford to invest in both at the same time, and to have them both work, but we made a bet as a company, and overall, I’m relatively comfortable with the results of that bet. Now we just have to take our position today and make sure it translates into leadership in that space, too. :) > Next up European/London presence: Where is PuppetConf Europe? Why are > the London Puppet User group meetings held in such a small space? Can > the next London Puppetcamp have an advanced track and speakers who > don't already have their slides for that talk on slideshare? These are > all exposure issues and without them the start of the community / user > pipeline doesn't stay filled. I really would love to have a PuppetConf Europe, but we just can’t afford it right now. All of our events run at a loss, no matter how much we charge or get sponsorship — both of which we also get a lot of complaints over — so we have to find the right balance between events to support the community wherever it is, and getting work done on other priorities. Every dollar I spend on an event is a dollar I can’t spend on things like developers, documentation, etc. > And lastly, and this is more anecdotal, the upgrade to Puppet 4. It's > a lot of work, it makes people nervous and other than iteration it's > not something that's immediately wish-list fulfilling for people. I've > been chipping away at prepping a large code base to puppet 4 and it's > something people dread the burden of rather than optimistic look > forward to getting new features from. Greenfield Puppet 4 is a big > step forward, it's just an even bigger one to get there if you already > have a large deployment. Agreed, and we’ve got work to do here. > I know quite a few places that are mostly cloud backed that would > rather move to the newer model of things like consul and consul > template than try to bring all their puppet up to scratch only to have > to do it again in what feels like another 6 months. The general > communities slow support of it has also created a cycle of pain where > important things module and provisioning platforms took a very long > time to justify and add the support for puppet and so caused a > downstream bottle neck of people finding out their tool chain was > puppet 3 only and deferring their own investigations again. I'll also > take this opportunity to single out the great work David Schmitt did > in helping bring Puppet 4 to puppet-syntax. That kind of outreach to > community projects should happen more. This is a fundamental challenge that every tool in this space will be wrestling with for as long as our space exists. I look forward to having these same arguments every 18 months or so, and to see them evolve in all of the other communities too. We’ve seen how hard this is, and we’re going to work differently from now on to focus incredibly heavily on reducing the cost of upgrade no matter what. It’s a company-level priority. — @puppetmasterd | http://about.me/lak | http://puppetlabs.com/ -- 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 puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/C06A033B-F607-44CB-8B6E-E3A122FA5489%40puppet.com. For more options, visit https://groups.google.com/d/optout.
