openstack team mailing list archive
Mailing list archive
[CHEF] How to structure upstream OpenStack cookbooks?
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
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
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
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.