openstack team mailing list archive

[Judd Maltin <judd@xxxxxxxxxxxxxx>]

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.abes@xxxxxxxxx> wrote:

> On Tue, Feb 28, 2012 at 3:21 PM, Jay Pipes <jaypipes@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>