Hank Beaver

Today’s topic, Libraries and including them in multiple Cookbooks. Any custom library loaded into a single Cookbook is available to all Cookbooks within your Node. So for example, let’s say you have a custom function that operates on Data Bags (like I do), it is available to all recipes. For example, if you include in a library one of your base/default cookbooks (like IPTables), then any other recipe can access those methods. The trick is that in your first recipe where you include your custom library, you have monkey patched Chef to include it thereafter:

class Chef::Recipe
  include DataBagHelper
end

So nice, now I have my custom library available everywhere. This makes me think, why not just have a custom library cookbook, or make my custom libraries part of my base/default recipe included in ALL nodes? So now I have my own methods and functionality available everywhere.

Sitting with Seth from Opscode today drinking some coffee. He pointed out a couple of things, I’d like to share.

1. Learn how to use Shef, to inspect node. It replaces ‘debug’ statements when doing runs in templates or recipes.

'shef -z'

2. If using Kinfe and a node is acting funny, inspect it via show or edit. For example, you might have to manually edit a run list or a default set of attributes that are an array instead of a hash (both real examples).
3. Stop using symbols for hash keys in recipes, cookbooks, etc. The Opscode default will be a double quoted string and older versions can just not work.
4. Upgrade to latest chef when overrides are not behaving as desired correctly OR override all the attributes for a recipe (even one’s you don’t want to override) if you are < 0.9.10. However, the latter solution is obviously less desirable.

That’s all for now.