A lot of things happened in the last month since the 0.7.4 release!
The MVP for this release is a new contributor, Grant Zanetti. Unfortunately we weren't able to secure a picture of Grant in time for the release post, but we imagine he's a handsome devil :-).
Grant had an itch to scratch with ticket CHEF-420 which decouples 'splay' (-s) from 'interval' (-i) for use in cron. He then went on to improve the JSON Editor, and fixed up a bug with the manage_home. Thank you Grant!
Of course, we had other contributors make Chef More Awesome for this release. Matthew "Lebron" Kent, our 0.7.0 MVP fixed up some specs. Joe Williams added support for multiple queue names on a single stompserver. This change means you can add a 'queue prefix' to have multiple queues available.
A huge shout out goes to the entire Chef community for helping us make Chef better for you. Filing and commenting on tickets benefits everyone, and we appreciate that. We also appreciate the efforts by Bryan McLellan and Matthew Kent in making Chef easier to package for Red Hat/CentOS and Debian/Ubuntu.
We have some important changes to tell you about for this release, in addition to those mentioned above.
The way you define Attributes in cookbook attributes files is updated, for the better. We've removed the requirement to define Mashes, protect values with cumbersome 'unless' statements, and we think you'll like the result. This doesn't break backwards compatibility, so you don't have to change your existing recipes, but after you see the example, we think you'll want to. We introduced two new methods, 'set' and 'set_unless' to do this.
Lets take an example out of the Opscode Apache 2 cookbook. First, the old method:
apache Mash.new unless attribute?("apache")
apache[:dir] = "/etc/httpd" unless apache.has_key?(:dir)
apache[:prefork] = Mash.new unless apache.has_key?(:prefork)
apache[:prefork][:startservers] = 16 unless apache[:prefork].has_key?(:startservers)
Now, the new method:
set_unless[:apache][:dir] = "/etc/httpd"
set_unless[:apache][:prefork][:startservers] = "16"
You can also use chained methods to do this if you prefer (more "ruby-like" to some):
set_unless.apache.dir = "/etc/httpd"
As you can see, we've reduced the amount of code, with the same results. The 'set_unless' method will set the attribute to the specified value unless it already has a value for this node. If you don't care about this kind of protection, simply use the 'set' method instead.
set[:apache][:dir] = "/etc/httpd" # or,
set.apache.dir = "/etc/httpd"
And that value will always get set.
The changes to attributes also allows us to have a change to Role attributes that Eric Butler filed a ticket about, and the attributes changes actually came about from this ticket. Basically with the old behavior, if you have a node defined, and you add a role to it, the node will be saved in the server with the Roles's attributes added, and if the Role is removed, the attributes persist. Along with the attribute changes that allow the above behavior, we can now remove the attributes a Role sets for us, without otherwise affecting the node. This makes it clean and easy to apply a role for a single run or for a limited time, and remove it later without worrying that the Role-specific settings will mangle the node.
Another signficant change is the removal of the specs from the installed Gems. This has a couple affects you should be aware of. Obviously, you won't be able to run specs from the installed Gem. Instead, you will need to grab the source from GitHub. Also, this reduces the size of the gem overall, and makes it easier to define what should be included in OS packages. If you're packaging Chef for your platform and would like to run spec tests, please see the README in the source.
People who use Passenger, or otherwise have the same Server URL for all the various places the client needs to contact a server will be happy about a new setting that allows such a default URL to be specified. With chef-client, use the -S option:
chef-client -s https://chef.example.com/
Or specify a configuration value in /etc/chef/client.rb:
This will reduce clutter in the file, and the number of places to update the URL.
For those of you keeping up with your metadata.rb, you may want to know that you can now specify versions with "major"."minor"."revision" numbering like many software packages use (like, Chef!).
Those of you using the rake tasks will probably be happy to know that the install task will now skip over .git directories when installing cookbooks in your server repository.
An old, persnickety bug where dotfiles were not getting pulled through the File Specificity mechanism was squashed.
Finally, chef-client and chef-solo will now report their run-time versions. More changes in the full release note changelog after the fold.
Opscode was busy as well. Our release maintainer this time around was AJ Christensen, and with feedback from the community, he was able to squash a number of bugs and integrate many of these improvements. Adam Jacob provided the fixes for attributes and some other bugs. Joshua Timberman was busy getting Chef itself packaged for Debian thanks to the packages already created by Bryan. We're just a few steps away from closing out CHEF-63 and having Debian/Ubuntu packages.
On to the release notes!
- [CHEF-87] – File specificity (preferred file) is broken by dotfiles
- [CHEF-357] – groupmod error with chef (0.6.2)
- [CHEF-371] – Link provider will not delete symbolic link if target does not exist
- [CHEF-394] – Last Check-in is only updated on the first run of chef-client, but not on later runs
- [CHEF-400] – Chef::Application#fatal! should log output to STDERR aswell, so errors are more plain
- [CHEF-406] – typos in specs, fix resulting failures
- [CHEF-407] – CHEF-308 breaks mount provider remote filesystem usage
- [CHEF-409] – run_list specified in json doesn't run the file caching step before trying to find recipes
- [CHEF-410] – Be able to have major, minor, revision for metadata version.
- [CHEF-411] – When a recipe is in the run_list and included, it may be run twice
- [CHEF-413] – why did chef gem get so big?
- [CHEF-415] – Error message clarity when a registration exists for the same hostname but the local secret doesn't exist / match
- [CHEF-416] – API roles, search integration features have failing steps
- [CHEF-423] – gentoo service provider enable action always runs for long service names
- [CHEF-431] – ChefServerSlice::OpenidServer#index should treat content_type as a symbol
- [CHEF-432] – chef-server-slice views should use slice_url instead of url
- [CHEF-433] – rake install should not copy .git files in addition to .svn
- [CHEF-436] – Default attributes from a role should not be written into the role's nodes
- [CHEF-437] – if manage_home is set to true but no home is set then home dir becomes -m
- [CHEF-439] – service resource – inherited file handle weirdness
- [CHEF-458] – File Cache stub missing
- [CHEF-463] – chef-solo and chef-client should display the version with –version (and optionally, -v)
- [CHEF-465] – chef-solo tries to get templates from localhost:4000
- [CHEF-467] – chef-server web ui doesn't load assets properly with 0.7.5
- [CHEF-373] – include specs in chef gem
- [CHEF-418] – Update readme for new integration tests
- [CHEF-427] – Minor cleanup of JSON Attribute editor
- [CHEF-430] – Add support for HTTP Basic Authentication to Chef::REST
- [CHEF-448] – allow a default URL definition in client.rb