Piping hot from the kitchen, I’m pleased to announce the release of both Chef 0.7.14 and Ohai 0.3.6. Thom May is awarded the MVP this release for fixing Chef to manage Yum correctly on CentOS4 with some well-appreciated Python skill. Go the snake charmer ;)
The secret sauce of this release however is definitely the Deploy resource, and the incredible amount of work put in by Daniel DeLeo. We received a large amount of feedback on varying deployment techniques and revised our strategies and behaviour appropriately. One of the main goals in Chef is idempotency, yet the deploy resource always operated in a timestamped, non-idempotent manner; to counteract this we’ve built the Deploy Revision/Branch provider. Administrators familiar with or interested in testing the Heroku style of idempotent deployment will welcome this change, I’m sure!
We took the opportunity to further solidify the behaviour ported across from the ‘chef-deploy’ gem, including two compatibility fixes: the deploy resource can now automatically install Gems listed in gems.yml and the ‘sudo’ and ‘run’ command-helpers are now usable during deployment callbacks
Lightweight Resources and Providers received a quick polish, enabling us to display the LWR/P components in the Chef Server Web UI. The ‘new cookbook’ Chef Repository task will also create the required directory structure for LWR/P usage.
It’s worth noting that no further releases in the 0.7.x branch are planned, however if any major bug arises we may ship a 0.7.16 release. All active development should now be targeted (and rebased where necessary) toward the 0.8 release, which will have 0.7.14 merged into it and replace the opscode/master branch over the coming weeks.
Debian packages were not created for 0.7.12 as it was a release candidate, but 0.7.14 packages will be available on http://apt.opscode.com by the end of the week. Please see the Packaged Installation wiki page for more information.
Release Notes – Chef – Version 0.7.14
- [CHEF-454] – Centos4 yum provider failure
- [CHEF-565] – dpkg provider fails at packages with a dash in it, causing packages to be re-installed on every chef run
- [CHEF-570] – Portage package provider uses wrong regexp in load_current_resource
- [CHEF-577] – provider.rb doesn’t give @definitions a default value of Hash.new, causing epic fail in resource DSL
- [CHEF-588] – RC is missing debugging info in find_preferred_file
- [CHEF-591] – if service doesn’t have a status command, process table inspection fails in simple service provider
- [CHEF-593] – deploy resource is not idempotent
- [CHEF-602] – in deploy provider, callback-defined resources are executed in all subsequent callbacks
- [CHEF-603] – deploy: gems.yml support
- [CHEF-604] – deploy: sudo / run command handler support
- [CHEF-614] – LWRP undefined local variable or method `new_resource’
- [CHEF-619] – Mixlib-* gems installed from gemcutter.org have too restrictive permissions
- [CHEF-621] – LWRP dynamic attribute methods are Ruby 1.9 incompatible and cause warnings in 1.8
- [CHEF-628] – Deploy resource removes newest release instead of oldest
- [CHEF-640] – SCM providers do not set resource updated (notifications)
- [CHEF-620] – LWRP components should be shown in Web UI
- [CHEF-622] – Gem Package resource/provider shouldn’t silently ignore the options attribute
- [CHEF-631] – Should create LWRP resources/providers for new_cookbook
Release Notes – Ohai – Version 0.3.6
- [OHAI-131] – ohai lies about its version
- [OHAI-134] – yajl-ruby causes incompatibility with json gem
- [OHAI-135] – include man page
Adjusted ETA for deb packages