Hi Joe -<br><br>Answers inline:<br><br><div class="gmail_quote">On Wed, Apr 27, 2011 at 9:55 PM, Jay Payne <span dir="ltr"><<a href="mailto:letterj@gmail.com">letterj@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Judd,<br>
<br>
I'm not that familiar with Chef (I'll do some research) but I have a<br>
couple of questions and some thoughts:<br>
<br>
1. Is this for a multi-server environment?<br></blockquote><div>Yes. <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
2. Are all your proxy nodes going to have "allow_account_management =<br>
true" in the configs? It might be a good idea to have a second proxy<br>
config for account management only<br></blockquote><div>I'm not sure - I don't know about the performance impact of such a config. <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
3. Have you looked at using swauth instead of auth?<br></blockquote><div>Not yet. <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
4. Have you thought about an admin or client node that has utilities<br>
on it like st and stats-report?<br></blockquote><div>Good suggestion. An admin node which is part of the cluster and not subject to the performance sensitivity of line of business nodes. <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
5. How where will you do on-going ring management or changes?<br></blockquote><div>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)<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
6. I would think about including some type of functional test at the<br>
end of the deployment process to verify everything was created<br>
properly and that all nodes can communicate.<br></blockquote><div>Good point - adding in validation steps and final functional test. <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<font color="#888888"><br>
<br>
<br>
--J<br>
</font><div><div></div><div class="h5"><br>
On Wed, Apr 27, 2011 at 6:18 PM, Judd Maltin <<a href="mailto:judd@newgoliath.com">judd@newgoliath.com</a>> wrote:<br>
> Hi Folks,<br>
><br>
> I've been hacking away at creating an automated deployment system for Swift<br>
> using Chef. I'd like to drop a design idea on you folks (most of which I've<br>
> already implemented) and get feedback from this esteemed group.<br>
><br>
> My end goal is to have a "manifest" (apologies to Puppet) which will define<br>
> an entire swift cluster, deploy it automatically, and allow edits to the<br>
> ingredients to manage the cluster. In this case, a "manifest" is a<br>
> combination of a chef databag describing the swift settings, and a<br>
> spiceweasel infrastructure.yaml file describing the OS configuration.<br>
><br>
> Ingredients:<br>
> - swift cookbook with base, proxy and server recipes. proxy nodes also<br>
> (provisionally) contain auth services. storage nodes handle object,<br>
> container and account services.<br>
> -- Base recipe handles common package install, OS user creation. Sets up<br>
> keys.<br>
> -- Proxy recipe handles proxy nodes: network config, package install,<br>
> memcache config, proxy and auth package config, user creation, ring<br>
> management (including builder file backup), user management<br>
> -- Storage recipe handles storage nodes: network config, storage device<br>
> config, package install, ring management.<br>
><br>
> - chef databag that describes a swift cluster (eg: mycluster_databag.json)<br>
> -- proxy config settings<br>
> -- memcached settings<br>
> -- settings for all rings and devices<br>
> -- basic user settings<br>
> -- account management<br>
><br>
> - chef "spiceweasel" file that auto-vivifies the infrastructure: (eg:<br>
> mycluster_infra.yaml)<br>
> -- uploads cookbooks<br>
> -- uploads roles<br>
> -- uploads the cluster's databag<br>
> -- kicks off node provisioning by requesting from infrastructure API (ec2 or<br>
> what have you) the following:<br>
> --- chef roles applied (role[swift:proxy] or role[swift:storage])<br>
> --- server flavor<br>
> --- storage device configs<br>
> --- hostname<br>
> --- proxy and storage network details<br>
><br>
> By calling this spiceweasel file, the infrastructure can leap into<br>
> existence.<br>
><br>
> I'm more or less done with all this stuff - and I'd really appreciate<br>
> conceptual feedback before I take out all the non-sense code I have in the<br>
> files and publish.<br>
><br>
> Many thanks! Happy spring, northern hemispherians!<br>
> -judd<br>
><br>
> Judd Maltin<br>
> T: <a href="tel:917-882-1270" value="+19178821270">917-882-1270</a><br>
> F: <a href="tel:501-694-7809" value="+15016947809">501-694-7809</a><br>
> A loving heart is never wrong.<br>
><br>
><br>
><br>
><br>
</div></div><div><div></div><div class="h5">> _______________________________________________<br>
> Mailing list: <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
> Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
> Unsubscribe : <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
> More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
><br>
><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Judd Maltin<br>T: 917-882-1270<br>F: 501-694-7809<br>A loving heart is never wrong.<br><br><br><br>