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