openstack team mailing list archive
Mailing list archive
Re: Multi-Cluster/Zone - Devil in the Details ...
On Feb 16, 2011, at 5:12 PM, Soren Hansen wrote:
> * Whenever I ask something for information and I get out-of-date,
> cached data back I feel like I'm back in 2003. And 2003 sucked, I
> might add.
The other side of that coin was the implementation of pub/sub. New/deleted/changed instances would publish these events, and the zones would update accordingly. So there should be no time travel back to 2003.
We had debated doing a regular polling to update, but pretty much everyone agreed that that would be especially sucky.
> * Doesn't this caching strategy only help if people are asking for
> the same stuff over and over? It doesn't sound very awesome if 100
> requests for new stuff coming in at roughly the same time causes a
> request to be sent to every single compute node (or whereever the data
> actually resides). I'm assuming breadth-first search here, of course.
Well, if we get 100 requests to spin up instances, each zone will know which hosts or sub-zones it needs to query, which is the information being cached. If the request is to spin up a new instance, the multi-cluster/zone traversal part will be the fastest part of the determination. What will be more time-consuming is the scheduler logic to determine the host for that instance, and that isn't dependent on how zones are arranged or how information about them is tracked and updated.
-- Ed Leafe