Inline...<br>
<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> Can someone explain _why_ we need caching?<br>
<br>
</div>        We don't *need* caching - it is simply the most direct way to avoid multiple expensive calls.</blockquote><div><br></div><div>So if we don't need it...?  You cite avoiding expensive calls, but I think it's entirely unproven that those call are too expensive. </div>
<div><br></div><div>If it makes you happier, think of the child zones as a cache that just happens to not have any inconsistency issues.  I see Eric's point that it would be better to integrate it up-front, but let's get ten zones working first, before we worry out how we can scale to ten thousand zones.</div>
<div><br></div><div>I think this should be Sandy's call.  My interpretation is that he'd like to implement a correct algorithm first, to understand where the bottlenecks are.  I think that's the right way.  Equally, if Sandy says he wants to do caching, then that's fine with me also.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> With our approach to pagination, without caching, the answer is always correct: each query always returns the next {limit} values whose ID is >= {start-id}.<br>
<br>
</div>        But for this example, you have to traverse *all* the zones in order to get the list of instances for a customer. How else would you define "instances 101-199 of 823 total instances"? How would you know where #101 is?<br>
</blockquote><div><br></div><div>You do need to traverse all zones, correct.  (Though note that you don't need to know where #101 is)  I think you may have missed the point about token-based pagination: the query is not "instances at indexes 101-199 of 823", it is e.g. "the next 100 instances whose id > 'i-198273'.</div>
<div><br></div><div>But how is this a problem?  How many zones are we talking about?  If this is bigger than a few dozen, why?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im"><br>
> I agree that in practice this means that there's no way to guarantee you get all values while they're changing behind the scenes, but this is a shortcoming of pagination, not caching.  Caching doesn't solve this, it just creates thornier edge cases.  The solution here is a more sensible ordering than 'last modified', and I question the value of pagination (other than for compatibility)<br>

<br>
</div>        The question is performance in this particular use case. As pvo said, you can accept a certain level of inconsistency as a trade-off for scaling. We would then allow the TTL to be controlled so that different OpenStack deployments can adjust this to their needs.<font color="#888888"><br>
</font></blockquote><div><br></div><div>Except every binding to the CloudServers API has a hacky way to bypass caching.  We have direct evidence that people don't want to accept these caching trade-offs / edge cases.</div>
<div><br></div><div>It sounds to me like you're saying: "But caching is web-scale" :-)</div><div><br></div><div><br></div><div>Justin </div></div><br>