← Back to team overview

openstack team mailing list archive

[CHEF] How to structure upstream OpenStack cookbooks?


Hi Stackers,

Chef configuration management allows a dizzying variability in the way that configuration is managed for a deployment. While this flexibility makes for a powerful overall system, it introduces a number of questions about what is the best practice for structuring a set of generally useful deployment pieces that can become the building blocks for more customized deployment configurations.

I'm hoping we can collectively find some answers so that we can push forward with currently proposed and future changes to the upstream cookbooks.

As a quick background, Chef's basic unit of organizing configuration and deployment information is the "cookbook". The cookbook is a collection of "resources" involved in the configuration of a particular component. Two of these resources are "recipes" and "roles". It's not particularly clear, however, what the best practice is for structuring what goes in a cookbook, a recipe, or a role.

Maru Newby recently proposed a merge to the openstack-chef upstream cookbooks that adds a Swift All-in-One cookbook:


Now, Maru added a new cookbook to the collection, called "swift-aio", and underneath that cookbook, added a number of recipes that set up some required Swift dependencies such as rsync. No roles were included in the merge proposal from Maru.

There were some code reviews that wondered whether the upstream Chef cookbooks should include stuff that was not intended for a production system -- as SAIO clearly is not -- but I'm wondering if it is possible to simply structure the cookbook in a way where we can get the best of both worlds: have resources that would allow a user to easily set up an SAIO environment as well as resources that would allow a user to deploy a production Swift installation on multiple nodes?

Specifically, these are the questions I'd like to discuss and get consensus on:

1) Do resources that set up non-production environments such as Swift All-in-One belong in the OpenStack Chef upstream cookbooks?

2) Should the cookbook be called "swift" instead of "swift-aio", with the idea that the cookbook should be the top-most container of resources involved with a specific project?

3) Is it possible to have a "swift" cookbook and have resources underneath that allow a user to deploy either SAIO *or* into a multi-node production environment? If so, would the best practice be to create recipes for SAIO and recipes for each of the individual Swift servers (proxy, object, etc) that would be used in a production configuration?

4) Instead of having an SAIO recipe in a swift cookbook, is it more appropriate to make a Chef *role* called swift-aio that would have a run list that contained a number of recipes in the swift cookbook for all the Swift servers plus rsync, loopback, etc?

I know that Maru and I very much appreciate your insights and answers to the above questions.

Thanks much!

Follow ups