Hacker News new | ask | show | jobs
by Woost 5390 days ago
I recently (past couple of months) had to look at chef vs puppet. I went with Chef, since it seemed easier to setup, and I liked the methodology behind it better. That said, there are a few issues around its choice of dependencies (solr, how I hate you).

Basically, I liked how chef treated the terminals as "dumb" and the configuration could be stored in source control. All of my nodes/"cookbooks"/recipes/users/data bags are stored in version control, with a few simple shell scripts to batch load the data. Also, chef nodes ping back to the server, which could cause problems (if you had tens of thousands of nodes hitting frequently), but also solves issues like "what if a server is offline when an important update should be pushed"

I believe that puppet has far more tools for seeing what's going on with your servers, when they last updated, that kind of thing. Also, the recipes/cookbooks you can get from the chef repository can be a little hit and miss (I had to heavily modify a few to make them work in my environment)

1 comments

Puppet also supports a 'dry run' mode to give you an idea of what changes would have been applied during a run - something Chef is lacking and definitely makes installing Chef on an already functioning machine a very scary proposition.

The built in reporting in Chef isn't very useful and the web ui is pretty light, but there's at least hooks and examples on how to extend it to meet your requirements.

Most of the Chef development so far appears to have been focused on core features and most recently a simplified installer - hopefully reporting will become a focus as the product matures.