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.le...@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 ab...@rackspace.com, and delete the original message. > Your cooperation is appreciated. > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
