Today we have a triple release of Chef, Ohai and Mixlib::Log, with more than 75 bug fixes, improvements, and new features.
Chef 0.9.10 features many improvements to knife. One of the most exciting improvements comes courtesy of Doug MacEachern: a bootstrap script for windows. The windows bootstrap uses VBScript and psexec to install Ruby and Chef on a remote host, so you need to run it from another Windows machine. Doug also added support for HTTP HEAD requests and custom headers to the http_request resource, which allows you to use If-Modified-Since to check if a file has been updated on the server before downloading.
Avishai Ish-Shalom fixed a common annoyance with knife ssh where if one host was down, the entire command would fail. Knife will now issue a warning for each host that it can’t connect to instead of failing outright. knife ssh also has much better messaging when required gems aren’t installed, thanks to former MVP Akzhan Abdulin.
Also new in knife this release is knife exec, which lets you runs scripts using all the new shef API interaction we added in 0.9.8. For example, you can add your new base role to all of your nodes with a one liner like this:
knife exec -E 'nodes.transform(:all) {|n| n.run_list << "role[base]" }'
To get acquainted with everything you can do with knife exec, start shef and run the help command, or check out the shef docs on the wiki.
Knife also gets a much more robust knife ec2 server create in this release. In previous versions of Chef, this command would often hang when connecting to the newly launched EC2 instance. The problem should now be completely fixed.
Thanks to John Alberts, knife now has a much friendlier error message when using knife cookbook site vendor with a misconfigured cookbook_path.
Another notable improvement in Chef 0.9.10 is that we’ve made it much easier to send notifications to resources when another resource is updated. Previously, you could only define a notification if the resource you wanted to notify was already defined, but now you can notify resources that are defined later in a recipe. For example, you can notify your webserver to restart when its config file changes like this:
template "/etc/www/configures-apache.conf" do
# other parameters
notifies :restart, "service[apache]"
end
service "apache" do
# parameters
end
For more detail about the new syntax, take a look at the updated docs on the topic. The old syntax for notifications will continue to work, of course.
We’ve got a lot of improvements to the way we index documents in Solr in the pipeline for Chef 0.10 but the first bit of work we’ve done is included in 0.9.10: chef-solr-indexer is about eight times faster than in 0.9.8. Part of this speedup comes from escaping data for XML using a C extension instead of a slower pure Ruby version. If you’re running a large Chef installation and want to take advantage of this speed improvement, just install the fast_xs gem on your chef-solr-indexer box and it will be used automatically. If you have a smaller Chef installation and you don’t want to deal with the additional dependency, you don’t have to do anything—Chef will fall back to the pure ruby code when fast_xs is not installed.
Among the community contributors to this release, there were two standouts: Toomas Pelberg and Tommy Bishop. Toomas and Tommy contributed a combined twenty patches to this release, so they are your 0.9.10 Co-MVPs. Toomas made a bunch of improvements to get our test suite working correctly on multiple platforms, which will make it even easier for new developers to hack on Chef, and also fixed a tricky bug with Chef’s handling of nil attributes. Thanks, Toomas!
Tommy Bishop is a relative newcomer to the Chef development community, but he hasn’t wasted any opportunity to make Chef better, fixing bugs in the route provider, subversion provider, Chef Solr, and Ruby 1.9 compatibility bugs in knife. Tommy includes extensive test suites with every patch, which is totally awesome.
The route provider also got some love from Jesse Nelson, who updated its internals to work correctly with refactoring we’d previously done on Chef’s internal run state handling.
New developers will also appreciate Christopher Peplin’s fixes to our README, which now accurately lists the gems required to get a development environment up and running. Of course, if you’re an aspiring Chef hacker, don’t be afraid to drop by the #chef-hacking channel on freenode where our developer community is ready to answer any development questions you have.
Matthew Kent continues to do great work, this time tracking down and fixing a tricky bug where the yum package provider could break when the showdupesfromrepos setting was enabled. Also on the RedHat/CentOS front, Gilles Devaux improved our bundled init scripts for those platforms.
The Web UI got a bit of polish this go-around, thanks to Dimitri Krassovski, who fixed a bug where roles were not being correctly highlighted when manipulating run lists, and Akzhan Abdulin who contributed a patch to display the Chef version. We also got some fit and finish in our error messages courtesy of Warwick Poole.
Michael Leinartas contributed a trio of tasty patches. Michael implemented the create_if_missing action for remote directories, fixed the notification system to check not_if and only_if before firing notified actions, and wrote a resource and provider for reloading ohai data. Nice work, Michael!
I’d also like to thank everyone who contributed by testing the RCs, participating on IRC and the mailing lists. Even though you might not show up in the commit logs, your help is invaluable in making Chef and the community around it awesome.
Mixlib::Log and Ohai also received minor updates today. Mixlib::Log 1.2.0 fixes a bug where the logger could inadvertently get initialized with incorrect settings. Ohai 0.5.8 brings Amazon Linux platform support and an updates its dependency on the JSON gem to match the update in Chef.
Since Chef 0.8.0, the chef-client has kept a cache of the checksums of the files it manages to avoid constantly recalculating them on subsequent runs. Unfortunately, Chef didn’t bother to clean up cached checksum files that had become irrelevant until 0.9.10. On older hosts, you may have hundreds of thousands of these stale checksum files in your /var/chef/cache/checksums (by default) directory. The very first time you run chef-client after upgrading, it will clean out the old checksums from this directory. If you have a huge number of these checksums, chef-client may peg a CPU for a short time while it clears them out. If you need to avoid this, you can simply delete all of the checksums from the directory with an out-of-band mechanism before upgrading.
If you are running Chef Server installed from Opscode’s Apt packages, be aware that the 0.9.8 (and earlier) packages were configured to store uploaded cookbooks in the same directory that the client used to store these cached checksums. The 0.9.10 packages will use an updated configuration to store the cookbook components and cached checksums in separate directories. Unfortunately, this means that the 0.9.10 apt packages will be delayed while we test the upgrade process.
Aside from those caveats, upgrading is as easy as installing the updated code. The client and server will work with any 0.9.x version of the other, so you can upgrade them as it’s convenient.