Hi Andi, Indeed, the swift recipes hadn't been updated since mid 2010, so I pushed forward with my own.
Thanks! -judd On Thu, Apr 28, 2011 at 10:03 AM, andi abes <[email protected]> wrote: > Judd, > > this is a great idea... actually so great, that some folks @Dell and > OpsCode, me included, have been working on it. > > Have a peek on : > https://github.com/opscode/openstack-cookbooks/tree/master/cookbooks > > This effort is also being included into Crowbar (take a peek here: > http://robhirschfeld.com/tag/crowbar/) which adds the steps needed to > start with bare metal (rather than installed OS), then using chef to get to > a working Open stack deployment. > (if you're at the design meeting, there are demos scheduled). > > That said - I'm updating the swift cookbook, and hope to update github > soon. > > a. > > > > > > On Wed, Apr 27, 2011 at 9:55 PM, Jay Payne <[email protected]> wrote: > >> Judd, >> >> I'm not that familiar with Chef (I'll do some research) but I have a >> couple of questions and some thoughts: >> >> 1. Is this for a multi-server environment? >> 2. Are all your proxy nodes going to have "allow_account_management = >> true" in the configs? It might be a good idea to have a second proxy >> config for account management only >> 3. Have you looked at using swauth instead of auth? >> 4. Have you thought about an admin or client node that has utilities >> on it like st and stats-report? >> 5. How where will you do on-going ring management or changes? >> 6. I would think about including some type of functional test at the >> end of the deployment process to verify everything was created >> properly and that all nodes can communicate. >> >> >> >> --J >> >> On Wed, Apr 27, 2011 at 6:18 PM, Judd Maltin <[email protected]> wrote: >> > Hi Folks, >> > >> > I've been hacking away at creating an automated deployment system for >> Swift >> > using Chef. I'd like to drop a design idea on you folks (most of which >> I've >> > already implemented) and get feedback from this esteemed group. >> > >> > My end goal is to have a "manifest" (apologies to Puppet) which will >> define >> > an entire swift cluster, deploy it automatically, and allow edits to the >> > ingredients to manage the cluster. In this case, a "manifest" is a >> > combination of a chef databag describing the swift settings, and a >> > spiceweasel infrastructure.yaml file describing the OS configuration. >> > >> > Ingredients: >> > - swift cookbook with base, proxy and server recipes. proxy nodes also >> > (provisionally) contain auth services. storage nodes handle object, >> > container and account services. >> > -- Base recipe handles common package install, OS user creation. Sets >> up >> > keys. >> > -- Proxy recipe handles proxy nodes: network config, package install, >> > memcache config, proxy and auth package config, user creation, ring >> > management (including builder file backup), user management >> > -- Storage recipe handles storage nodes: network config, storage device >> > config, package install, ring management. >> > >> > - chef databag that describes a swift cluster (eg: >> mycluster_databag.json) >> > -- proxy config settings >> > -- memcached settings >> > -- settings for all rings and devices >> > -- basic user settings >> > -- account management >> > >> > - chef "spiceweasel" file that auto-vivifies the infrastructure: (eg: >> > mycluster_infra.yaml) >> > -- uploads cookbooks >> > -- uploads roles >> > -- uploads the cluster's databag >> > -- kicks off node provisioning by requesting from infrastructure API >> (ec2 or >> > what have you) the following: >> > --- chef roles applied (role[swift:proxy] or role[swift:storage]) >> > --- server flavor >> > --- storage device configs >> > --- hostname >> > --- proxy and storage network details >> > >> > By calling this spiceweasel file, the infrastructure can leap into >> > existence. >> > >> > I'm more or less done with all this stuff - and I'd really appreciate >> > conceptual feedback before I take out all the non-sense code I have in >> the >> > files and publish. >> > >> > Many thanks! Happy spring, northern hemispherians! >> > -judd >> > >> > Judd Maltin >> > T: 917-882-1270 >> > F: 501-694-7809 >> > A loving heart is never wrong. >> > >> > >> > >> > >> > _______________________________________________ >> > Mailing list: https://launchpad.net/~openstack >> > Post to : [email protected] >> > Unsubscribe : https://launchpad.net/~openstack >> > More help : https://help.launchpad.net/ListHelp >> > >> > >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp >> > > -- Judd Maltin T: 917-882-1270 F: 501-694-7809 A loving heart is never wrong.
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
