Some jobs “could go either way”. For example, let’s say you want to change the default Apache config. You could use Chef to fix the config at runtime, or you could package up a new Apache with a fixed config. Either way is sane.

But let’s say you manage virtual hosts, and you have to get the hosts from the database and update various Apache config files. Of course any admin would start writing shell scripts.

But down the road, you’ll find a mess of shell scripts with implicit dependencies. For example, today you happen to need to run 3 scripts, and each one needs to restart Apache. How do you make sure Apache gets restarted, but make sure it doesn’t get restarted 3 times? Or how do you document the ordering and dependencies of your scripts, especially those that aren’t run often? Chef deals with issues like that.

(On the other hand, I think people should start with Chef Solo [because that's the hard part -- learning the 'language' and writing recipes]. Later, install Chef client/server so you can centralize both your cookbooks and your configuration. Then you can do really neat tricks like “find all the databases on all my mysql servers” or “what version of perl is installed on these servers?”)

On the dependency topic, we’re not trying to spread any FUD about Puppet. It is simply a different approach. As you are probably aware, with Puppet you have to specify dependencies between resources (or with 0.25.0, classes). The difference with Chef is it processes recipes in the order specified. This is covered in the FAQ and on our blog. I believe the config management panel at OSBridge earlier this year covered the topic as well.

http://blog.opscode.com/2009/01/9-things-to-like-about-chef.html (Dependencies, Ordinality and Expectations)

http://wiki.opscode.com/display/chef/FAQ (how is it different than puppet)

Joshua here. Just to clarify, Joel had initially responded via comment, not me. I hope my email helped, though. If you run into further issues, please email the mailing list, or stop by #chef on IRC and we’ll help you get up and running.

Thank you!

Hello Erik!

I’m sorry to hear you’ve had some trouble getting up and running with Chef. I work for Opscode, and I’m primarily responsible for helping people implement Chef in their environment. Let me address some of the concerns you brought up in your blog post.

Documentation, installation: First off, I’m responsible for maintaining the documentation and making sure the installation procedures work as broadly as possible. Obviously I can’t test every single environment possibility, but I try to reach the most common.

IRC help: We might have missed your queries! Please don’t be discouraged, we try to be as helpful as possible, but if you’re not seeing any response on IRC, please post to the Chef mailing list[0]. Be sure to include detail about your environment and relevant configuration and logfiles.

Ubuntu packages: The Debian/Ubuntu packaging process is detailed (which is why APT is so awesome!), it is a lengthy process, and it is difficult to get new packages into current releases. Now that Chef is in Ubuntu Karmic, it will be easier to get Chef packages into the other releases of Ubuntu and Debian through backporting and syncing. In the meantime, you may be interested in the APT repository where we host Chef and its dependencies[1].

RubyGems: When using the Debian/Ubuntu rubygems package, binary programs aren’t copied to /usr/bin like with stock RubyGems, and instead live in /var/lib/gems/1.8/bin, which is not in the user’s default path. This may be confusing to some people. The packaged RubyGems also tends to lag quite a bit behind the current releases. We initially released Chef and associated software (Ohai, the Mixlibs) as Gems because for Ruby software, it is the most common distribution method, and works on any platform. Yes, Chef even installs on Windows .

Server log: This is resolved for the next release (0.7.10) per ticket CHEF-500[2].

Server doesn’t work: Please try IRC again, or post on the mailing list. Keep in mind that Chef relies on the fully qualified domain name (FQDN) being set correctly on the server and also on clients. An incorrectly set FQDN causes a number of common problems, including SSL errors in the Apache+Passenger server stack.

Production readiness: We certainly think that Chef is production ready, it manages our own infrastructure . Several users in the community are also using Chef for their companies, including 37Signals[3], Engine Yard[4], and others.

I hope these explanations help. If you need further assistance, please stop by #chef on FreeNode, my nick is jtimberman.

[0] http://lists.opscode.com/sympa/info/chef
[1] http://bit.ly/aptopscode
[2] http://tickets.opscode.com/browse/CHEF-500
[3] http://37signals.com/svn/posts/1872-nuts-bolts-configuration-management-with-chef
[4] http://www.engineyard.com/cloud-services/solo (uses chef-solo)

Debian and Ubuntu packages have been released
OpenID is getting removed in the next version in favour of keypairs (although you can setup your own OpenID internal provider)

The issues you faced with logging in must be entirely down to your infrastructure or lack of knowledge. Chef is very choosy about using FQDNs (as it should be, that might have been your issue).

After testing out every configuration management tool under the sun for the past 6-9 Months, I can honestly say that Chef is by far the best.

Horses for courses, but I think your analysis of the software is hampered by your lack of understanding.

Good luck with the other tools if you try and use them!