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. 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. 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. 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. 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. Dean -- Dean Wilson http://www.unixdaemon.net Profanity is the one language all programmers understand --- Anon -- 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/CAFbDO0ens%2BEA1%3DTmZvGJz8CeoQzER5xF8m465Zo3A%2BKUtmOwUg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.