Chef-client cookbook changes coming


#1

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


#2

The COOK-2319 service changes are on master. Test Kitchen support in the repository is updated and everything looked good.

COOK-2856 and COOK-2858 are in a pull request (#1000). Please test! To do so, you can clone the repository and check out the jtimberman/COOK-2856 branch. Test kitchen can be run (read the TESTING.md file), or you can upload the cookbook to your Chef Server - use environments to pin the version so you don’t overwrite prod of course.

Please leave feedback on COOK-28561.

Thanks!
Joshua

On Jun 7, 2013, at 11:43 AM, Joshua Timberman joshua@opscode.com wrote:

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