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 

> 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 

-- Ed Leafe

Mailing list: https://launchpad.net/~openstack
Post to     : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Reply via email to