Hi Joe - Answers inline:
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? > Yes. > 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 > I'm not sure - I don't know about the performance impact of such a config. > 3. Have you looked at using swauth instead of auth? > Not yet. > 4. Have you thought about an admin or client node that has utilities > on it like st and stats-report? > Good suggestion. An admin node which is part of the cluster and not subject to the performance sensitivity of line of business nodes. > 5. How where will you do on-going ring management or changes? > Rings are defined in a Chef "DataBag". When the databag is updated, Chef detects the file change. When the chef-client runs on the nodes, they pick up the config changes. Scheduling and orchestrating the chef-client runs will also be expressed in the data-bag (or from an orchestration server) > 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. > Good point - adding in validation steps and final functional test. > > > > --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 > > > > > -- 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
