Open Stack

Ed,

I would agree. The caching would go with the design tenet #7: Accept
eventual consistency and use it where it is appropriate.

If we're ok with accepting that the list may or may not always be up to
date and feel its appropriate, we should be good with the caching.

pvo


On 3/16/11 11:45 AM, "Ed Leafe" <ed.leafe at rackspace.com> wrote:

>On Mar 16, 2011, at 12:23 PM, Paul Voccio wrote:
>
>> Not only is this expensive, but there is no way I can see at the moment
>>to do pagination, which is what makes this really expensive. If someone
>>asked for an entire list of all their instances and it was > 10,000 then
>>I would think they're ok with waiting while that response is gathered
>>and returned. However, since the API spec says we should be able to do
>>pagination, this is where asking each zone for all its children every
>>time gets untenable.
>
>    This gets us into the caching issues that were discussed at the last
>summit. We could run the query and then cache the results at the
>endpoint, but this would require accepting some level of staleness of the
>results. The cache would handle the paging, and some sort of TTL would
>have to be established as a balance between performance and staleness.
>
>
>
>-- Ed Leafe
>