Open Stack

On Mar 16, 2011, at 2:24 PM, Justin Santa Barbara wrote:

> Can someone explain _why_ we need caching?

	We don't *need* caching - it is simply the most direct way to avoid multiple expensive calls.

> 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}.

	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?

> 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)

	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.



-- 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.