Hey everyone! Try-it vs. Very-complex: Separate projects, with links to eachother in the READMEs.
Production: I use my chef recipes in production. Some more organizing and some re-thinking has to go into them to work well. I'd like to start that conversation in another thread, after taking a second look at where other folks have gone with the Swift recipes. I'd reference again my blue-sky blog entries from last summer on Swift and Chef. I still run my cluster that way, but what I've learned since then needs to be integrated. Patches welcome! -judd On Feb 28, 2012 5:33 PM, "andi abes" <andi.a...@gmail.com> wrote: > On Tue, Feb 28, 2012 at 3:21 PM, Jay Pipes <jaypi...@gmail.com> wrote: > > cc'ing Maru since his particular cookbook is being discussed here : > > > > > > On 02/28/2012 02:56 PM, andi abes wrote: > >> > >> yes and no.... > >> > >> One neat feature of chef is it's search capability - being able to > >> query the sever of where other pieces of the puzzle are located, which > >> makes it very convenient for multi-node operations. > >> E.g. for swift there are a few cookbooks floating around where by the > >> rings are constructed by locating all the servers that are tagged as > >> "storage" nodes (i.e. they have the appropriate role(s) assigned to > >> them. > >> While "search" is a neat capability, it does make the recipes more > >> complex (recipes are part of cookbooks, that express the operations to > >> be performed). So if the intent is to have the cookbooks serve as an > >> newbie exemplar, showcasing openstack - its probably not a good idea. > >> > >> Other complexities arise when you start dealing with machine variably, > >> that can be easily hidden in SAIO. Using swift as an example - the # > >> and device names of disks. In SAIO, you just create a bunch of > >> loopback devices... (at least the sample deployment docs do). On a > >> more (dare I say) "production" environment, you'd want to discover > >> what disks are available, and use the appropriate ones. > >> > >> That said - there could be recipes for both SIAO and multi-node. Users > >> would then have to combine and apply the right set. But maybe that's > >> not the full question... maybe a more ""complete"" question would be: > >> > >> is this effort geared towards producing deployments that can be > >> considered "production ready"? > > > > > > I believe most people would answer "Yes". The openstack-chef upstream > > cookbooks should be geared towards production environments. > > > > I was just asking if there is the ability to have both production-ready > > recipes and "try this out" recipes all in the same repo. Sounds like > that's > > not really a good thing, and if not, we should decide where the > appropriate > > place to put "try this out" recipes should be? > > > > Didn't mean to say that's not a good idea.. (the try-it part), or not > possible. My main goal was just to double check that indeed a > production deployment is envisioned. > A simple option to ease any possible confusion between the different > recipes could be to have separate cookbooks- e.g. swift and swfit-saio > or maybe openstack and openstack-saio. > > > However, the mention of "production" raises a few other questions > (again.. I think I'm just echoing) - specifically what's the source of > the OpenStack bits to be used... > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
