Open Stack

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 at rackspace.com> 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 at rackspace.com, and delete the original message.
> Your cooperation is appreciated.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110316/f5b31123/attachment.html>