Chef wrapper cookbook best practices

Question

In learning chef, I see conflicting patterns for wrapper cookbooks. For example.

Some cookbooks use default.rb and others use customize.rb for overrides.

Answer 1

There is very little in the way of best practices out there, sadly, but there are a few gotchas to be careful about.

Attribute loading order

Attributes files are loaded (Executed) in a very specific, albeit not very clear, order.

1. The required cookbooks are resolved based on the runlist and metadata for each cookbook referenced in the runlist, and all dependencies.
2. Once a list of involved cookbooks has been compiled, they are ordered lexigraphically.
3. The attribute files from each cookbook are then ordered lexigraphically.
4. Execution starts at the to of the list, however, if an include_attribute statement is encountered, that attribute file will be immediately executed (and removed from the list so that it is not executed a second time.)

This is important because if the same attribute is set at the same level ie default by more than one attributes file, then the last file to execute will determine which value wins. __So always include_attribute the attribute file from your library cookbook at the top of the attribute file for your wrapper cookbook. Then set attributes at the default level (so that they can more easily be overridden elsewhere).

One of these things is not like the others

Normal attributes (node.set or node.normal) are a funny beast. They persist between chef runs. So once you set an attribute to normal, it will stick around until you either remove it, or change it. Sometimes this is a good thing, like a uuid you want to remember, but sometimes it is an unexpected side effect.

Style

symbols and strings, and methods, oh my.

There is a LOT of debate regarding node.attribute, node[:attribute], and node['attribute'] access styles. Just read up on foodcritic 001 if you want to see both sides of the coin. In my opinion, node['attribute'] has won the majority of community cookbook developers, but it is a pretty slim majority. node.attribute is almost universally frowned upon because it can have evil side effects. Ultimately, you use what you like best, but if your library cookbooks are fairly consistent, I'd suggest you follow their convention.

Where to override

Personally, I try hard to never set an attribute outside of an attributes file. It too often leads to headaches. It's just easier to keep all attribute set operations in the attributes files, so you can easily hunt them down. But there are times when you either cannot do it in the attributes file, or it just makes more sense in the recipe. As with most programing rules, you just have to weigh consistency with what feels right.