openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

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:

https://review.openstack.org/#change,3613

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!
-jay