openstack team mailing list archive

[andi abes <andi.abes@xxxxxxxxx>]

I like where this discussion is going. So
I'd like to throw a couple more sticks into the fire, around test/SAIO
vs production deployments..

* Swift cookbooks (and in general) should not assume control of system
side resources, but rather use the appropriate cookbook  (or better
yet "definition" if it exists). e.g rsync might be used for a variety
of other purposes - by other roles deployed to the same node. The
rsync (not currently, but hopefully soon) cookbook should provide the
appropriate hooks to add your role's extras. Maybe a better example is
the soduers cookbook, which allows node attributes to describe users &
groups.

* SAIO deployments could probably be kept really simple if they don't
have to deal with repeated application - no need to worry about
idempotency which tends to make things much harder. A greenfield
deployment + some scripts to ""operate"" the test install are probably
just the right thing.

* Configurability - in testing, you'd like things pretty consistent.
One pattern I've been using is having attribute values that are
'eval'ed to retrieve the actual data.
For example - the IP address/interface to use for storage
communication (i.e. proxy <-> account server)  a node attribute called
"storage_interface" is evaluated. A user (or higher level system) can
assign either "node[:ipaddress]" (which is controlled by chef, and
goes slightly bonkers when multiple interfaces are present) or be more
opinionated and use e.g
"node[:crowbar][:interfaces][:storage_network]"






2012/3/9 Matt Ray <matt@xxxxxxxxxxx>:
> 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
>>
>>
>
> Thanks,
> Matt Ray
> Senior Technical Evangelist | Opscode Inc.
> matt@xxxxxxxxxxx | (512) 731-2218
> Twitter, IRC, GitHub: mattray
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp