[eblume]

I really don't intend this as a brag, but I just wanted to point out that I learned Puppet yesterday. No, I mean, I really learned it yesterday. I started with my company's vagrant-managed VM and took their existing puppet architecture, and armed with that I learned (from no previous experience) how to write Puppet manifests, modules, 'define's, etc.

My only point is that it doesn't take two weeks to learn Puppet. I'm not saying that Ansible is worse or anything like that, rather I just wanted to contribute another data point.

[mpdehaan2]

I think the issue is not so much the question of how long it takes someone to learn a tool, but the repeated cost you get get from using it on a day to day basis. (I'd still be super impressed if you had storeconfigs and the spaceship operator nailed in a day!)

For instance, I worked for a major computer vendor doing an OpenStack deployment, and watched a simple deployment there suck up 20 developers for six months, where all of that time was in writing automation content.

Repeated hammering out of dependency ordering issues, coupled with the non-fail-fast behavior, and having to trace down where variables came from turned us into automation tool jockeys, so we couldn't focus on architecture and development. The project barely had deployments extending beyond 5 nodes in the end from all of the complexity.

Ansible already existed at this point, but it provided major fuel for me doubling down efforts into expanding it. The goal here is not just the basic language primatives, but making it really easy to find things as you have a large deployment, and making it really easy to skim/audit even if you aren't a really smart programmer.

That all being said, Puppet deserves major credit for pioneering a lot of concepts and revising CFEngine.

While Ansible aims to be a cleaner config tool, but also focuses on application deployment and higher level orchestration on top, so you get some capabilities not found in those other chains (like really slick rolling update support).

[eblume]

Thanks for the helpful comment and also for Ansible in general! I'll take a good, close look at it - you might find me in your IRC channel sometime soon as I poke around Ansible, trying to see if it might be a good idea to port things over.

I know we were looking at Boxen as a way to roll out environments to our dev machines, and we are hoping that our existing Puppet configs will work well with that effort (since Boxen uses Puppet). Do you think it's at all possible that there will be some sort of adapter to allow Boxen to use Ansible? I have no idea if that would a good idea or not (I haven't looked in to either Boxen or Ansible enough yet) but that's the sort of thing that would likely help steer our decision process.

[mpdehaan2]

Sure thing -- Jesse Keating has been working on a side project called 'ansibox', which is effectively about taking boxen like ideas and applying them to Ansible. He's 'jlk' in #ansible and you should stop by and say hey. It's new, but it has the same kind of 'choose what you want and we'll make it for you' kind of workflow.

[mechanical_fish]

You're tinkering with an existing, working architecture and a company-maintained Vagrant VM?

Of course it's going well. But you should make sure to buy all the people who built all these well-engineered things a tasty drink at the next company get-together, because rest assured: Not every Puppet setup is easy to tinker with.

[eblume]

I absolutely do, and having a working environment is a huge help! However I found the puppet docs to be more than sufficient, and in fact I spent the day learning puppet not through our existing code (which actually needs a fair bit of work still) but rather using the learning VM that Puppet provides on their website.

[gazarsgo]

i, on the other hand, tried to learn puppet over the course of a weekend with a brand new laptop and Boxen just after it was released. There is a nightmare of broken dependencies that still aren't resolved months later (librarian-puppet won't install apache because apache's version has a -rc in it which isn't a ruby version blah blah blah...)

now I know that using VMs / vagrant is critical to sane server orchestration development workflows though, so there's that.

[eblume]

Interesting! We do use librarian-puppet but we do not use apache. It's possible that we just managed to step around that land mind essentially by accident. Did you run in to any other issues?