-----BEGIN PGP SIGNED MESSAGE-----
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
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?
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
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
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
∙ [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
∙ [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
∙ [CHEF-433] - rake install should not copy .git files in addition
∙ [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
∙ [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
∙ [CHEF-274] - Add support for multiple named queues on a single
∙ [CHEF-414] - add symlink owner/group support
∙ [CHEF-420] - Decouple usage of -s from -i
Posted with links on Opscode’s Blog: http://bit.ly/chef076
Joshua Timberman, Senior Solutions Engineer
C: 720.878.4322 E: email@example.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
-----END PGP SIGNATURE-----