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
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
