Studio, Thursday, 11:00

• Convener / Facilitator
• Note taker: blame @zts

Q: Who has written a cookbook?

A: all (~20)

Q: Who has refactored a cookbook using different patterns?

A: ~10

Similar session at the Seattle summit, check notes for more advice about patterns people have used successfully.

Facebook cookbooks cited as having some interesting patterns, notably extensive use of attributes for driving behaviour.

Q: Using the node attribute in templates vs explicit use of variables?

A1: Variables block gets evaluated at compile time, use of node attribute will only be dereferenced when the template is interpolated.

A2: Several people expressed a preference for using variables to make the interface explicit.

Q: Do lazy attributes work on template variables?

A: Should do, maybe for the whole variables block vs individual keys

Q: Who's not using berkshelf?

A: 2 people, but the berkshelf users have not all embraced the berkshelf way

Recap about the environment cookbook pattern. If you're doing this, the berkflow tool can be useful to help guide the process. Check out the berkshelf-api cookbook, which gives an example of using the environment pattern.

Q: What patterns do you use when implementing community cookbooks to make them easier to wrap?

A: Parameterise use of include_recipe.

A: Look at the rvm cookbook's evolution

At the Seattle summit, use of chef-rewind was being considered an antipattern - if you need to use it, it's a sign that the original cookbook could be improved.

Q: Refactoring (part of) a recipe into a definition?

A: Smallest change that moves the cookbook into the right direction - good as a first step, then consider moving to LWRPs.

Q: Has anyone written HWRPs?

A: 1 hand

Q: Has anyone tried out using Poise?

A: Two people aware of it, no real use

Noted that @miah's work on her redis cookbook takes an interesting approach, looks more like (is?) a rubygem.

But note the windows cookbook breaking because of gem dependencies - consider how packaging cookbook deps as gems introduces a new place for things to break. What patterns can be used to avoid this? Suggestion: ship the gem as a cookbook file.

Q: Patterns / how to document cookbook interface? (attributes, etc)

A1: (several people) Moving in the direction of resources for reusable cookbooks

A2: (others) Attribute overrides are important in our infrastructure, but we take care to limit where attribute overrides can be declared. See also Facebook, again.

Q: Tools to help verify/insist that certain cookbooks adhere to certain patterns?

A: chefdk has a generate command, to build a cookbook skeleton. This might be helpful? Maybe chefdk should have more generators/scaffolds, eg "chef wrap " - engage with the RFC process if you think this is a good idea!

Observation: Pulling configuration from databags encourages refactoring to resources, to avoid shim recipes that stuffs keys into attributes.

Response: databags feel more like global data than attributes, need to take care with how they're used to avoid unexpected consequences. See also https://coderanger.net/data-bags/

Q: Issue with chefspec, needing to repeat stubs/mocks (eg, for guards)

A: Thinking about this from the ruby perspective, large number of mocks can be a code smell - does this signal something that could be extracted?

Q: Stories from people refactoring cookbooks - what and why?

A: ran out of time for this

• Something like c2 patterns wiki, but for Chef?
• RFC for chefdk generators for cookbook patterns?