Chef sat down with Dan Webb of the Sous Chefs organization recently for a Q&A session. Dan is a winner of a 2018 Awesome Community Chef award for all of his contributions and mentorship to the Chef community. (These answers have been edited and condensed for clarity.)
We’re a group of about 20 or 30 Chefs who maintain Chef cookbooks, modernize them, and keep them up to date. We keep to best practices, which could be anything from using custom resources to writing good READMEs. We’ve been around for about four years.
haproxy, line, samba, postgresql and mongodb are all Sous Chefs cookbooks that you might have heard of. We just released version 7 of the PostgreSQL cookbook at ChefConf, for example. That one really pushed the edges of what Chef can do. We’ve completely dropped recipes everywhere and moved to custom resources. All the unreliable parts of that cookbook have been removed.
We just brought in two language packs for editors, one of which is the Chef language pack for Atom. It helps you write both custom resources and recipes, so if you don’t quite remember the syntax, you can just start typing a resource – say, file – and it will pop up a drop-down list much like Visual Studio Code, and links you to the documentation if you want to go straight there.
Yes. If you’re writing an application cookbook, custom resources are fantastic, as you give the user a good clean API and abstraction layer between you and the application you’re installing. In the PostgreSQL example, you just write postgresql_database and then do/end blocks and you give us a bunch of properties as you do for the file resource. You can loop over that in a wrapper cookbook to manage all your databases. It’s nice and clean.
We also extract all helper methods into libraries. So if you ever see the word def, that’s going in a library. We’re now testing resources and libraries with just RSpec because it’s just plain old Ruby code. It makes testing much easier.
We’ve gone pretty hard on InSpec. Actually, because we’ve got a set of custom resources and a test cookbook that exercise the cookbook in certain ways, we can then point users to the test cookbook for documentation which is a double win there. We’ve got tests and documentation all in the same place. If anyone ever looks at the tests, it should be easy to spot what’s going on.
For integration testing we spin the cookbook up with Test Kitchen. Then we use InSpec to verify. InSpec’s a standard default across all the cookbooks we use. If you ever see any BATS we’ll probably be removing that even if we end up doing the very same thing underneath with InSpec.
We have a plethora of CI tools. Right now, we’ve got Travis CI for most of the testing. We use Appveyor for Windows. We also use CircleCI for reporting back to a tool called Danger. Danger helps us look for human errors in the cookbook. For example, “Hey, you’ve made a PR with more than 400 lines of code. Did you really want to make a big change like that?” Usually, the answer is no. It helps develop good practices from a human level as well. Danger isn’t as sophisticated as, “Hey, you’ve missed a test.” It’s stuff like, “Hey, you probably wanted to make a changelog entry there,” and things like that. It’s easier to write the changelog when you make the commit rather than having to sift through a hundred commits two months later when you want to release it.
There’s a big “Get Involved” section on the Sous Chefs website. If you’re interested in transferring a cookbook to us, there’s a section about that. We really like people to engage with the community first of all, before doing any of these things. Either pop into the Sous Chefs channel on Chef Community Slack, or you can also talk with us on GitHub. There’s a meta project on Sous Chefs where you can discuss transferring cookbooks to us for example.
We have a ton of cookbooks and less active people than cookbooks, so we’d like to reduce the bus factor. I think between Aaron Kalin, Tim Smith, and myself, we probably maintain 50% to maybe 80% of the cookbooks, mostly because we have historically maintained a lot of cookbooks ourselves anyway. Pretty much any cookbook you want to help maintain, we will take you in as a maintainer. I would rather have ten maintainers and have a very long release process and many conversations about how to do things than have one person who disappears for six months as they get busy, which is historically what happened with all of these cookbooks. That’s what Sous Chefs the organization is designed to avoid actually.
We can use some graphic designers, so our Sous Chefs website doesn’t look like it was designed by engineers for engineers. I have no design blood flowing in my body, so if anyone’s looking at the website we would appreciate you asking a UI person to come along & help out.