← Back to team overview

openstack team mailing list archive

Re: [CHEF] How to structure upstream OpenStack cookbooks?


I agree with some of the replies from Rafael, but I have a few
suggestions (inline).

2012/3/9 Rafael Durán Castañeda <rafadurancastaneda@xxxxxxxxx>:
> Hi,
> Bearing in mind I'm no really a Chef expert:
> On 03/09/2012 04:58 AM, Jay Pipes wrote:
>> Hi Stackers,
>> 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?
> I think this kind of recipes help a lot new stackers and I can't see any
> reason for not include them.

If the openstack-chef cookbooks are going to be examples for
implementations, including SAIO makes sense.

>> 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?
> I think so

If there's not a lot of overlap or shared attributes between the
multi-node Swift cookbook and the SAIO cookbook, having them separate
makes more sense so it's easier to maintain them separately.

>> 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?
> I think if you split your cookbooks on small reusable components you can
> combine them so you get a SAIO, proxy, whatever.... with little or not extra
> effort

For the Nova cookbooks I've written (haven't done Swift yet), I had a
role for 'nova-single-machine' that was just a special case of
multi-node and reused all the multi-node recipes. I would propose
including the 'swift-aio' as a separate cookbook for now and have the
goal of ensuring that there is a 'swift-single-machine' role that
works with the 'swift' cookbook. This might take some additional work,
so keep both sets of cookbooks for now in case it doesn't get the
attention it needs.

>> 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 think this is good practice. As I said before having small reusable
> components you can combine them getting all what you need, and probably the
> best place for combining them is roles. You can of course include smaller
> cookbooks into bigger ones and get the same result, but I prefer role based.

See my previous comment. I too prefer role-based.

> HTH,
> Rafael

Matt Ray
Senior Technical Evangelist | Opscode Inc.
matt@xxxxxxxxxxx | (512) 731-2218
Twitter, IRC, GitHub: mattray

Follow ups