openstack team mailing list archive

[Paul Voccio <paul.voccio@xxxxxxxxxxxxx>]

For Cactus, I'm with Justin and Sandy on #1 to get something working.

Justin — you said earlier that you're not sure this is going to be a problem. From experience, this is a problem with trying to query all the instances across zones for Rackspace now. Sandy and others including myself have talked though this a few times to try to solve this early, but I don't think we can. I, like you, want to get something working with zones asap. I'd rather retreat from trying to solve this now to get something working. We'll obviously tackle the list instances once something works.

From: Justin Santa Barbara <justin@xxxxxxxxxxxx<mailto:justin@xxxxxxxxxxxx>>
Date: Wed, 16 Mar 2011 13:37:50 -0700
To: Ed Leafe <ed.leafe@xxxxxxxxxxxxx<mailto:ed.leafe@xxxxxxxxxxxxx>>
Cc: "openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>" <openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>>
Subject: Re: [Openstack] A single cross-zone database?

Seems that the person writing the code (Sandy) wants _not_ to do a single DB initially.  It sounds like there are back channels where a single DB is being pushed on Sandy.

To me, it sounds like we have these choices:

  1.  We can have a zones implementation in Cactus.  As specified in the blueprint, it will use recursive querying, and there will be no caching initially, nor will there be a single DB.
  2.  We can go 'off blueprint', and simply not have a multi-zones implementation in Cactus.

Given that, I don't see why we would deviate from what we've agreed (and I'm normally all for flexibility); let's get a baseline implementation into Cactus.  People that want to add caching or a single DB are then free to do so in their own branches, but at least those enhancements will be starting from a common base.  I'm not against adding caching / a single DB if it proves necessary / good later.

Hopefully we'll actually learn of any real-world issues with the simple approach by running Sandy's code, and we can discuss those facts at the design conference, rather than talking in hypotheticals.

Sandy: Have I got the wrong end of the stick here?  Are these our choices?

Justin



On Wed, Mar 16, 2011 at 1:13 PM, Ed Leafe <ed.leafe@xxxxxxxxxxxxx<mailto:ed.leafe@xxxxxxxxxxxxx>> wrote:
On Mar 16, 2011, at 3:39 PM, Justin Santa Barbara wrote:

> I agree that we could have a better marker, but I'm just going off the spec at the moment.
>
> I've checked the agreed blueprint, and caching in zones is out of scope for Cactus.
>
> Please propose a discussion topic for the Design Summit.

       Can we get back to the original topic? The only reason caching came up was as an alternative to a single DB to hold all instance information. That was an implementation solution suggested for multi-cluster/zones, so it is definitely in scope for Cactus.



-- Ed Leafe



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace.
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse@xxxxxxxxxxxxx<mailto:abuse@xxxxxxxxxxxxx>, and delete the original message.
Your cooperation is appreciated.


_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx> Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp