Puppet vs Chef, Fight

Could it be you made the wrong design decisions both times? Sometimes, people try to do complex things in puppet, when they should using puppet just to push out that cronjob or init script, or rpm/apt package to handle the complexity.

Can you give more details like how many serves you have? Do you have a complex combination of hardware(physical + virtual) and operating system platforms?

Do you have a complex combination of apps on these platforms? Did you use the "environments" feature of puppet/chef? (Environments are totally broken in puppet) Did you use Dashboard/Foreman or Grill(chef only) and did that make things easier?

Did you migrate from the "hairball nest of Bash and Perl that holds your data center together" or did you build your infra from scratch with puppet/chef?

What are some examples of things are really elegant to express in Puppet? What are some examples of things that you had to resort to terrible hacks for?

Please use personal, concrete examples, if you don't mind.

I've only got a couple of boxes to manage, but reading through the docs for the big three configuration management systems, I really was confused about the need for most of the stuff in the tutorials. I'd also be interested in concrete examples of where shell-scripts fail so badly.

Sorry, that part was irony. I would of course recommend CM. I was just trying to express that the current crop of tools is nowhere near a level of maturity where you could recommend one or the other as a no-brainer.

Could it be you made the wrong design decisions both times?

Surely. More so with puppet than with chef as the puppet language offers slightly more rope to hang yourself on the foot. However, I'm quite confident we have maxed out both tools to about the best of their abilities now (short of the more esoteric extensions such as mcollective). There is of course always a next step, but I can't think of something that could potentially change my perception of their respective problem areas (which, as I outlined in my parent post, are pretty fundamental for each tool).

Can you give more details like how many serves you have?

Largest puppet deployment is ~70 hosts, largest chef is ~40 hosts.

Yes, we've had to migrate the puppetmaster to a pretty beefy host. Yes, chef's claim to scalability is a joke. We experimented with couch replication but quickly went back to running separate (beefy) chef-servers and sync'ing them via git.

A tangential reason for running separate puppetmaster/chef instances is the lack of a trustworthy security model in both. Extdata/databags do occasionally contain sensitive information, neither puppet nor chef accounts for that (don't get me started on "encrypted databags").

Do you have a complex combination of hardware(physical + virtual) and operating system platforms?

We run (only) debian on physical and cloud servers. For cloud deployments chef works better for us. For physical servers we're rooted in puppet but slowly leaning towards chef for uniformity. I wouldn't say our deployments are especially complex. And even if they were then that'd be no excuse for the tools that were created to manage precisely that kind of complexity.

Did you migrate from the "hairball nest of Bash and Perl that holds your data center together" or did you build your infra from scratch with puppet/chef?

The bigger clusters were built from scratch but we have chef/puppet clusters in various states of finesse.

Oh, this reminds me of one of the less obvious issues that I forgot in my initial rant: Updates.

You absolutely, positively want to either update your entire cluster (all puppet/chef clients) in lockstep with the server or not at all. The "backwards compatibility"-claims didn't work out for us when we tried.

This will assemble a hosts-file that contains all hosts from $group, on the hosts that include the class.

It's awesome and terrible at the same time because it demonstrates an Exported Resource (@@host, Host >, awesome) and at the same time it shows how we had to resort to extdata for grouping (extlookup = terrible) and how opaque the puppet DSL is to the uninitiated.