openstack team mailing list archive
Mailing list archive
Re: Multi-Cluster/Zone - Devil in the Details ...
On Feb 16, 2011, at 10:26 AM, Sandy Walsh wrote:
> But this introduces a problem. Consider this use-case:
> a. I issue a "create-instance" via the top-level API in zone-A
> b. the request is relayed down to zone-C
> c. the instance is created some time later
> Q1. How does the user learn what the instance is named? For example, I want to issue a "pause-instance" but don't know what to give as an instance ID?
Isn't the instance name usually supplied by the user/originator?
> 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.
> One alternative is to make Host-Best-Match/Zone-Best-Match stand-alone query operations.
> My above use-case would look like this:
> a. I issue a "find-best-zone" command to the top-level API in zone-A
> b. I get an API URL to zone-C
> c. I do my "create-instance" on zone-C, as well as all related 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.
-- Ed Leafe