openstack team mailing list archive

[Ed Leafe <ed@xxxxxxxxx>]

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