openstack team mailing list archive
Mailing list archive
Re: Multi-Cluster/Zone - Devil in the Details ...
On Feb 16, 2011, at 11:54 AM, Sandy Walsh wrote:
> Thanks for feedback Ed. Comments in  below ...
Yeesh - that makes for ugly quoting. :) Let me try to reformat the quoting.
>> Isn't the instance name usually supplied by the user/originator?
> [Sorry, yes the instance name is passed in on the request, but the instance ID is what's needed (assuming of course instance ID is unique across zones.)]
The ID is determined early in the process; well before the request to create an instance is cast onto the queue, and is returned immediately.
>>> Q2. If I do "instance-list", do I have to search all zones again?
>> If the db is not centralized/replicated, yes. Caching could certainly be an option, especially in situations where instances tend to persist for long periods.
> [The db is not centralized. One per Zone.]
I know that. I'm just stating that this is a natural consequence of the decision not to use a centralized db.
>>> One alternative is to make Host-Best-Match/Zone-Best-Match stand-alone query operations.
>> I don't really like this approach. It requires the requester to know too much about the implementation of the service: e.g, that there are zones, and that an instance will be placed in a particular zone. I would prefer something more along the lines of:
>> a. User issues a create-instance request, supplying the name of the instance to be created.
>> b. The top-level zone that receives the request does a zone-best-match and/or host-best-match call to determine where the instance will be created.
>> c. The top-level zone then passes the create-instance request to the selected zone/host.
> [But what about subsequent actions ... the same zone-search would have be performed for each of them, no?]
This was one of the issues we discussed during the sprint planning. I believe (check with cyn) that the consensus was to use a caching strategy akin to DNS: e.g., if zone A got a request for instance ID=12345, it would check to see if it had id 12345 in its cache. If not, it would ask all of its child nodes if they knew about that instance. That would repeat until the instance was found, at which point every upstream server would now know about where to reach 12345.
-- Ed Leafe