<div>some response inline followed by general comments on the topic</div><br><div class="gmail_quote">On Sat, Mar 10, 2012 at 9:30 AM, andi abes <span dir="ltr"><<a href="mailto:andi.abes@gmail.com">andi.abes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I like where this discussion is going. So<br>
I'd like to throw a couple more sticks into the fire, around test/SAIO<br>
vs production deployments..<br></blockquote><div><br></div><div>I think there are some misconceptions that lead to problems.</div><div><br></div><div>If your SAIO/test diverge from production deployments, what are you really testing?</div>
<div><br></div><div>If you really understand what configuration management tools are for, the recipes are code that is going through the same cycle.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

* Swift cookbooks (and in general) should not assume control of system<br>
side resources, but rather use the appropriate cookbook  (or better<br>
yet "definition" if it exists). e.g rsync might be used for a variety<br>
of other purposes - by other roles deployed to the same node. The<br>
rsync (not currently, but hopefully soon) cookbook should provide the<br>
appropriate hooks to add your role's extras. Maybe a better example is<br>
the soduers cookbook, which allows node attributes to describe users &<br>
groups.<br></blockquote><div><br></div><div>I agree in principle.</div><div><br></div><div>This is good practice in general, but in specific can require a lot of understanding and discipline to separate the recipes. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* SAIO deployments could probably be kept really simple if they don't<br>
have to deal with repeated application - no need to worry about<br>
idempotency which tends to make things much harder. A greenfield<br>
deployment + some scripts to ""operate"" the test install are probably<br>
just the right thing.<br></blockquote><div><br></div><div>If you find yourself writing chef with the idea that you don't need to worry about idempotency, you aren't doing configuration management, you are writing an installer. You are almost better off using bash. Part of my position here also stems from my position that these recipes shouldn't be different.</div>
<div><br></div><div>You might think I'm being zealot, and relatively speaking, you might be right, but from my experience the extra work to do this upfront pays itself back many times over. Also, I can show you where the real zealots live. :)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Configurability - in testing, you'd like things pretty consistent.<br>
One pattern I've been using is having attribute values that are<br>
'eval'ed to retrieve the actual data.<br>
For example - the IP address/interface to use for storage<br>
communication (i.e. proxy <-> account server)  a node attribute called<br>
"storage_interface" is evaluated. A user (or higher level system) can<br>
assign either "node[:ipaddress]" (which is controlled by chef, and<br>
goes slightly bonkers when multiple interfaces are present) or be more<br>
opinionated and use e.g<br>
"node[:crowbar][:interfaces][:storage_network]"<br></blockquote><div><br></div><div>This gets to the heart of one of the reasons why there is so much variation in the wild.</div><div> </div><div>chef allows for almost infinite flexibility for how information gets into the system and how it gets used.</div>
<div><br></div><div>Further, there is a tension between specificity and discovery.</div><div><br></div><div>By that I mean one can either specify a specific value, in cookbooks, roles or databags, or you can discover values from the running systems.</div>
<div><br></div><div>This is a spectrum and there is not always a 'right' answer. Both have value and both can become problematic. Context, opinions and philosophy of the author are typically what determine the details of a given cookbook.</div>
<div><br></div><div>I'll attempt to make this more concrete. How do you want to deploy and manage the filesystems and devices for rings of Swift?</div><div><br></div><div>One on end of the spectrum, parameterize an attribute with all the devices that will be in the ring, with the obvious alternative being that some procedure and convention gets the devices from the running systems.</div>
<div><br></div><div>This is also a tension between knowing and doing, and leads to a bunch of other questions.</div><div><br></div><div>In the case where a specified device is missing/failed, what should the behavior be? If doing discovery, is there a method to sanity check what the devices should be?</div>
<div><br></div><div>Both cases only get more complicated when considering on going management of the cluster, adding/removing capacity etc.</div><div><br></div><div>Operational scenarios start begging the question of what should be managed with chef at all. (they also beg the question of whether there should be some more automated ring management in Swift itself)</div>
<div><br></div><div>This is just one example, but I hope it illustrates the point.</div><div><br></div><div>My current personal preferences/bias:</div><div><ul><li>Do not make 'installers' with configuration management tools</li>
<li>Stand alone recipes should not be separate. If they do exist, it is as part of the initial pass to get a working cookbook with the intent to refactor to more generalize cookbook. AIO should then be a role</li><li>lean towards specificity supported by tooling to manage the metadata for node specific configuration</li>
<li>utilize discovery for cross node configuration (of the data that was specified for the other nodes)</li></ul></div><div>I'm not saying I'm right, just that I've seen and tried things a few different ways and this seemed to work best in my context.</div>
<div><br></div><div>So to answer Jay's explicit questions:</div><div><br></div><div><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">1) Do resources that set up non-production environments such as Swift All-in-One belong in the OpenStack Chef upstream cookbooks?</span></div>
<div><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">I vote no. Not as a cookbook. As a role, maybe.<br>
<br>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?</span></div><div><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">Assuming you allow aio to be separate, this is a better organization IMHO. If the AIO can't be just a role parameterization, the proximity hopefully encourages more modularity and reuse.<br>
<br>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?</span></div>
<div><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span class="Apple-style-span" style="border-collapse:collapse;color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">Possible. Recipes can be composed. There is clearly one way to do all this, but getting to some combination of modular recipes parameterized by roles is going to be better than a series of disparate monolithic cookbooks in the long run. (even if it seems like more work now)<br>
<br>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?<br>
</span></div><div><font class="Apple-style-span" color="#222222" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse:collapse"><br></span></font></div><div><font class="Apple-style-span" color="#222222" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse:collapse">In my opinion, this is more appropriate.</span></font></div>
<div><font class="Apple-style-span" color="#222222" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse:collapse"><br></span></font></div><div><font class="Apple-style-span" color="#222222" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse:collapse">0.02 + interest</span></font></div>
<div><font class="Apple-style-span" color="#222222" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse:collapse">Andrew</span></font></div></div>