Ohai Chefs,
I wanted to let you all know about some changes coming to Opscode’s chef-client cookbook. There are important notes here regarding backwards compatibility.
TL;DR:
We recommend that you pin your use of the chef-client cookbook to the released 2.2.4 version. The master branch will get changes described below, which may break compatibility. We want to minimize this, but we can’t predict everyone’s use of this cookbook.
Plan accordingly :).
Background
The chef-client cookbook has existed for a long time. Originally, it was used to configure /etc/chef/client.rb and a chef-client daemon service with chef-solo, before we had knife bootstrap and friends. The config recipe may be less necessary with knife bootstrap, but the service management recipe is important because our Omnibus package doesn’t install a service.
Given its age and scope over time, the cookbook has undergone a number of changes, particularly adding support for other platforms in the service management recipes. Overall it works, but there are changes that require a fair amount of refactoring. This is all collected under a task ticket:
http://tickets.opscode.com/browse/COOK-2855
Some of the more important foundational changes are described below.
Config Recipe
Work tracked in this ticket:
http://tickets.opscode.com/browse/COOK-2856
This adds a new sub-attribute, node[‘chef_client’][‘config’]. In the client.rb.erb, we walk through this hash of options and their values, and write out the /etc/chef/client.rb. The commit referenced in the ticket has an initial implementation.
We plan to also implement a “conf.d” style of configuration inclusion via COOK-2858.
http://tickets.opscode.com/browse/COOK-2858
This will allow users to drop off any arbitrary additional configuration for /etc/chef/client.rb similar to other tools that do “configuration includes.”
Service Recipes
Via COOK-2319
http://tickets.opscode.com/browse/COOK-2319
We’ve split up the “service” recipe into multiple recipes, one for each “service type” (init, runit, smf, etc). Now the init_style attribute will include the appropriate recipe. Or, you can opt to just include the service recipe you want on the appropriate nodes.
This ticket also covers some use cases of running chef-client on a node that is also the chef-server.
Call for Testing
We need your help testing. As I mentioned, we can’t imagine every use case here. While we can’t workaround all changes, we do want to make the next version as widely useful as possible.
Please help test. Normally we don’t recommend the master branch for cookbooks but obviously the released version won’t have these changes yet.
Compatibility
We’ve tried to make everything backwards compatible as much as possible. However, this is definitely one of those “have to break some eggs to make an omlette” topics. We feel that the benefits outweight the negatives here, especially for those who want more flexibility out of this cookbook. This also builds directly on work we’re doing internally, so we will use this too :-).
The target Chef version for this cookbook is Chef 11. After scanning through COOK, I didn’t see any obvious show stopping bugs for the current version on Chef 10, so 2.2.4 should work for most folks.
Cheers,
Joshua