
Facebook Chef cookbooks - orrsella
https://code.facebook.com/posts/1909042435988955/facebook-chef-cookbooks/
======
willejs
So do you encourage people to add tests to their wrapper cookbooks when they
consume these? I read the philosophy and readme docs, and I kindof get what
your doing with attribute precedence, and how these cookbooks are sane
defaults with overrides. Why not move to custom resources? Also, what's your
feelings about the chef monolithic repo?

~~~
jaymzh
Using custom resources, like LWRPs, doesn't provide the same flexibility. Most
of the time you fall into making something which works akin to the `cron`
internal resource which doesn't provide managing an entire system but instead
a single entry which means you get neither automatic cleanup nor automatic
fall back [to an earlier value]. It also means there's no good way to stack
configs. You can (obviously) build a resource which manages the entire
file/subsystem (poise does this, for example), but even then, you don't get
the ability for everyone to override things later in the run... and we want
the final service owner to be able to change anything anyone before them has
set. It's a key part of being able to scale people... and for us to have such
a small core chef team (4-5 people).

In addition, using simple hashes and arrays makes it much simpler for your
average software engineer to make changes they want - they have to learn
little to no Chef in the simple case... even not knowing ruby they can figure
out variable assignments.

The monolithic repo works well for us given we use grocery-delivery
(github.com/facebook/grocery-delivery). We have no environments (see my
ChefConf keynote in 2013 for a full breakdown of how we do run things) and no
cookbook versioning... we run directly off of head. We use a combination of
taste-tester (github.com/facebook/taste-tester) for general testing and and
sharding (see `node.in_shard?` and `node.in_flexible_shard?` in the
`fb_helpers` cookbook) to control the speed of rollout of risky changes.

To be clear we use no precedences at all except `default` - using other
precedences will in fact likely break our model since it causes the node-read
code to merge things rather than treating it like a single hash. The model
here is last-writer-wins always.

As for tests, people consuming these cookbooks are simply assigning variables,
so there's not a lot to test in a wrapper cookbook. "Did the attribute get the
value I assigned it" doesn't seem like a useful unittest... that should be
covered by Chef's unittests itself. For our more complicated cookbooks we've
unit-tested the API and where we could we released those (see fb_fstab), and
we have some other unittests we haven't yet been able to release that
hopefully we'll come back around to.

Hope that helps, \- Phil

------
brudgers
Cookbooks repository: [https://github.com/facebook/chef-
cookbooks](https://github.com/facebook/chef-cookbooks)

