Update on the Future of Opscode’s Cookbooks

This is an update on the blog post we made a couple weeks back regarding the future of Opscode’s cookbooks and cookbooks repository. We are going to switch master branch to reflect the changes that have been made in the 0.10.0 branch this week. Aside from removal of a number of cookbooks (which has been done in the 0.10.0 branch), we’ve made several other important changes you should be aware of.

Chef Environments

Several cookbooks that used search also used an “app_environment” attribute which generally came from a role of the same name. This has been replaced with the node’s chef_environment. If you don’t specify an environment for the node, _default will be used instead. This may have adverse effects if you’re using multiple “environment roles”, so you should be careful about upgrading cookbooks to the newer version. The following cookbooks on the community site do not have this change as of the stated version:

  • application 0.99.9
  • database 0.99.0
  • haproxy 0.8.1
  • munin 0.10.1
  • nagios 0.4.4
  • radiant 0.11.3

Newer versions of these cookbooks released to the community site will use Chef 0.10’s environments.

If you’re using the cookbook repository directly, the commit for this change in the repository is 93aedac, you’ll want to make sure you have not updated to that commit until you’re ready to use Chef 0.10’s environments.

Metadata JSON

We maintain cookbook metadata as Ruby DSL files and let knife generate the metadata as JSON. In the updated repository, we have removed the metadata.json files. The reason is, prior to Chef 0.10.0 the metadata was generated in the cookbook directory as “metadata.json” every time a cookbook upload was done. Depending on the local system’s Ruby version, this might cause the file content to be different. When using the Ruby DSL metadata.rb file, there is no need to generate the metadata.json file by knife (cookbook upload and site share commands). To simplify maintenance and prevent these from possibly being forgotten and stale, we simply removed them from the repository. If you prefer the JSON file, you can generate it and remove the metadata.rb file in your own repository.

This change in Chef is reflected by the following tickets:

Consistency

We’re not quite done, but we’re actively working to make the cookbooks more consistent. What this means:

  • Attributes will use the quoted string notation, e.g. “node[‘apache’][‘listen_ports’]”.
  • Each cookbook will have a README.md. We chose markdown because it is more universally parsable by tools and text editor plugins than RDOC.

We’ll continue to work on these tasks after we’ve moved the branches around in the repository.

Upcoming Steps

The branch formerly known as “0.10.0” is now “future”. We’re going to take the following steps with regard to the repository this week.

  • Ensure the current master is updated.
  • Rebase the “future” branch with current master.
  • Tag repository with “future-freeze” to reflect the point in time where the cookbooks are now.
  • Create a “future-freeze” branch at this same point in time. This is where users who use the GitHub repository as a whole repository, or sub-module should be updated. As the name implies, this will be frozen, and we won’t actively maintain it.
  • Merge the current working branch, “future” into master. This will reflect the changes described in the previous blog post and above.
  • Push master, the “future-freeze” tag and upload cookbooks to community site.

Once the master branch reflects what we’ve planned here, we’ll maintain “master” as we did before. We’re also going to release new versions of the cookbooks to the Community Site.

Author Joshua Timberman

Joshua Timberman is a Code Cleric at CHEF, where he Cures Technical Debt Wounds for 1d8+5 lines of code, casts Protection from Yaks, and otherwise helps continuously improve internal technical process.

  • > Attributes will use the quoted string notation, e.g. “node[‘apache’][‘listen_ports’]“.

    Any particular reason for that? IMO symbol notation (node[:apache][:listen_ports]) looks so much nicer and is easier to type. I suppose if you have keys that don’t work as symbols would be a reason not to use it. Just wondering.

    • Hi Nathan!

      Nothing is stopping you from using the symbols as keys, we’re just doing this in what we’re shipping because of the principle of least surprise. A string as a key will behave the same consistently.