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 : firstname.lastname@example.org Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp