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.<div><div><br></div><div>To me, it sounds like we have these choices:</div>
<div><ol><li>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.</li><li>We can go 'off blueprint', and simply not have a multi-zones implementation in Cactus.</li>
</ol></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Sandy: Have I got the wrong end of the stick here?  Are these our choices?</div><div><br></div><div>Justin<br><br>
<br><br><div class="gmail_quote">On Wed, Mar 16, 2011 at 1:13 PM, Ed Leafe <span dir="ltr"><<a href="mailto:ed.leafe@rackspace.com">ed.leafe@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mar 16, 2011, at 3:39 PM, Justin Santa Barbara wrote:<br>
<br>
> I agree that we could have a better marker, but I'm just going off the spec at the moment.<br>
><br>
> I've checked the agreed blueprint, and caching in zones is out of scope for Cactus.<br>
><br>
> Please propose a discussion topic for the Design Summit.<br>
<br>
</div>        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.<br>

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