Today I’m very happy to announce the release of Chef 0.9.0, Ohai 0.5.6, and mixlib-config 1.1.2. Chef 0.9.0 Brings some new features, a ton of under-the-hood cleanup, and lays the foundation for some big improvements ahead on the roadmap.
The biggest update is to chef-servers’s cookbook handling: chef-server now can store multiple versions of cookbooks. In support of this addition, we’ve reworked the way cookbooks are uploaded to and stored on the server, so files are now uploaded individually, and organized on disk by the checksum of their contents. This means that when you upload an updated cookbook to the server, only the updated or newly added files will need to be transferred to and stored on the server. We’ve also introduced transactional behavior in the uploading process, so clients will always get a consistent view of their cookbooks, even if they’re running while you’re updating the cookbooks. Chef isn’t making much use of this functionality yet—the latest versions of cookbooks are still used almost everywhere—but we’re really excited about the upcoming features we’ll be able to provide because of it. Specifically, in an upcoming release, chef will give you the ability to define the different environments that comprise your infrastructure, such as QA, staging, and production, and pin specific versions of cookbooks to each environment.
We’ve also got a huge bump in our Windows support, thanks to our MVP, Doug MacEachern of VMware. Doug has added an environment provider that lets you automate the process of setting your environment variables, user and group support, and the ability to mount filesystems on Windows. Doug has also written a ton of plugins for ohai, and he even takes the time to write vbscripts to set up chef-client for his in-laws!
In this release, we’ve updated our handling of attribute precedence, fixing CHEF-838 and CHEF-45. You can now access the default and override attributes in your attribute files, which were previously only accessible in roles. This allows you to set default attributes in your attribute files with syntax like this:
default[:mysql][:bind_address] = '127.0.0.1'
default[:mysql][:datadir] = '/var/lib/mysql'
Previously, that syntax would set the values only if they had not previously been set. Now, it will always set the attribute at the lowest precedence, allowing you to override these attributes via node data or roles. Continuing the example, users of this cookbook would be able to override these defaults in their roles, like this:
default_attributes :mysql => {:bind_address => '0.0.0.0'}
This value can be further overridden by setting a mysql[:bind_address] attribute on the node, or with an override attribute in a role. We now recommend using the default keyword to set attributes in any recipes you plan to share. This will
give users of your cookbooks the most predictable behavior, and maximum flexibility in tailoring the attributes to their specific needs.
We’ve also moved attributes from ohai into a special “automatic_attrs” category. These automatic attributes have the highest precedence, and cannot be overridden by even an override attribute. This is really helpful when editing node attributes, as now the ohai data will be separated from the attributes you explicitly set on the node. For those of you upgrading from 0.8.x, you’ll need to run a migration on your existing nodes to purge ohai data from the normal node attributes. See the “upgrading” section below for more details.
Chef 0.9.0 is also the first version of Chef to fully support Ruby 1.9. On the server side, we’ve updated Chef to run on Merb 1.1.x, which was the last dependency we were waiting on for 1.9 support. On the client side, we’ve found and fixed a tricky issue with mixlib-config where Ruby 1.9 clients were incorrectly using default values for some configuration parameters. If you’re running chef-client on Ruby 1.9, be sure to update your mixlib-config to pick up this bug fix. We’ve already got a few eager adopters running on Chef on Ruby 1.9.2 preview 3 without issue, so if you’re comfortable running ruby 1.9 in production, you can bring Chef along for the ride.
In this release we also have expanded support for Solaris thanks to Toomas Pelberg, who contributed a provider for the service resource on Solaris.
Avishai Ish-Shalom changed our default backup behavior from storing the backups in the same directory, to storing the backups in a parallel tree. This solves an issue where updating a file in a conf.d directory would leave the backed-up file in the same
directory and both files would be used by the application (you can enable the old behavior by setting the file_backup_path to nil in your client.rb configuration file). Avishai also contributed a patch to ohai to parse EC2
security groups into an array. Thanks, Avishai!
Our 0.8.16 MVP, Akzhan Abdulin, did not rest on his laurels. This time around, he found and fixed an issue where Chef was not setting the Content-Length header on POST and PUT requests, which was causing issues when running a chef server cluster behind nginx. Akzhan also made the webui sort nodes by name, so they’ll be easier to find, and patched ohai to support network devices with underscores in the name.
Joshua Sierles, in addition to being one of the earliest adopters of this release and providing invaluable testing for the attribute precedence updates, fixed the ability to access automatic attributes in attribute files.
Alexey Ivanov fixed a bug in Chef’s handling of installed zypper packages that have updates available.
Previous MVP Ian Meyer contributed some tasty fixes, including my personal favorite, CHEF-1337. Ian also updated our Solr schema so it won’t accidentally
interpret string fields as integers or floats, added a sweet knife status command, cleaned up our test suite, and fixed an authorization issue in the WebUI.
Another early adopter this time around was Joe Williams, who found and fixed an issue showing nodes in the Web UI using the release candidate. Thanks for testing and for the patch, Joe.
Renaud Chaput, our 0.8.14 MVP, fixed a bug with knife where we had added the -f switch to set the output format, but this switch was already used to direct output to a file. The -F switch will now be used to define the output
format.
Matthew Kent, who’s responsible for making Chef a snap to install on Red Hat and related distributions with his RPM packages, contributed manpages and other materials he’d created during packaging, and also patched the file provider to bypass checksumming when it’s not managing content.
We have a few more improvements from Opscode to announce in this release. The first is an updated rubygems package provider which uses rubygems’ ruby API. This fixes the lingering issues we’ve had with the changes in rubygems 1.3.7, and gives us an impressive speed boost in the process: in our tests, the new provider is 300–2000 times faster when the desired gem is already installed.
Finally, this release introduces a notification API: you can now configure chef-client to run notification handlers after each successful or unsuccessful chef-client run. An example will best explain the capabilities, so here’s a simple handler that simply logs the run status using Chef’s logger:
LogItHandler < Chef::Handler
# Define a report method to run your notification logic
def report
# write your notification code here.
# you can access the start_time, end_time, node, exception (if any),
# backtrace (if any), success/failure status of the run, and a list
# of all resources and all updated resources. Be careful, these can
# be nil if chef crashed very early in the run.
Chef::Log.info("report for #{node.name}")
Chef::Log.info("run completed in #{elapsed_time} seconds")
if success?
Chef::Log.info("Updated #{updated_resources.size} of #{all_resources.size} resources")
else
Chef::Log.info("Sad panda: chef run failed with exception #{exception.inspect}")
backtrace.each {|line| Chef::Log.info(line) }
end
end
In your client configuration file, you enable the handler like this:
report_handlers << LogItHandler.new # these fire at the end of a successful run
exception_handlers << LogItHandler.new # these fire at the end of a failed run
In this release, we’re deprecating some previously valid cookbook syntax. Before I discuss the specific changes, I’d like to make it clear that the old syntax is deprecated but not removed. The deprecated syntax will continue to work for the foreseeable future; Chef will simply log a deprecation warning whenever the deprecated syntax is used. At some point in the future, we will decide on a “drop dead date” for the deprecated syntax, and embed that date in the deprecation messages. So, what do you need to do about it? Just start using the new syntax whenever you write a new recipe or update an existing one. We’ll keep you updated as we move through the deprecation process. With that out of the way, let’s look at what’s been deprecated:
cookbook_file resource and provider for accessing files stored in the files directory of cookbooks, and deprecated the use of remote_file for this
purpose. We think the new name expresses the intent—synchronize a file from a cookbook—more clearly than does “remote file.” Remote file still exists for the purpose of fetching files from arbitrary locations on the web,
however.@node instance variable in recipes is similarly deprecated. Instead, access the node via the node method.Upgrading to 0.9 from 0.8 is a much smoother transition than from 0.7 to 0.8, but there are still some pitfalls to be aware of. First of all, 0.9 chef-clients can read from 0.8 servers, but cannot save to 0.8 servers. 0.8 chef-clients cannot read from
0.9 chef servers at all, so you will need to upgrade your clients and server in lock-step. As a consequence of the new cookbook upload process, chef-server has two new configurable locations where cookbooks are stored. These are configured with the
sandbox_path and checksum_path parameters in your server.rb; they default to /var/chef/sandboxes and /var/chef/checksums, respectively. If you previously installed chef-server via the
bootstrap recipe and used the default /srv/chef path for chef server data, you will probably want to set these new configuration parameters to match:
# snippet of server.rb for a bootstrapped chef-server using /srv
sandbox_path "/srv/chef/sandboxes"
checksum_path "/srv/chef/checksums"
Another consequence of the new cookbook uploading and storage logic is that you will need to re-upload your cookbooks after you upgrade your chef-server.
With that in mind, the basic upgrade process for chef-server is described below. As always, remember to make backups and try the upgrade in a test environment first.
sandbox_path and checksum_path, edit the server configuration file (server.rb).knife cookbook upload -a -o /path/to/cookbooks from a machine with chef 0.9 installed.We’re very proud of the improvements in this release and how far we’ve come, but we’re even more proud of the community that’s formed around Chef. We’re constantly impressed by everyone taking the time to help each other get started with chef, troubleshoot problems, share tips, tricks, and insights on IRC and our mailing lists. If you have any questions or need any help, just stop by.