Hi y'all Like they say "The devil is in the details". I'm at the stage where the parent zones will talk to the child zones and there are some interesting implementation issues:
Problem 1. I'd like to pass the incoming HTTP Request object along to the Scheduler so I don't have to remarshall the command to send to the child zone. Rather than modify all the *service/api.py methods to accept a request parameter, can anyone think of cleaner solution? I debated piggy-backing on the Context, but that's ugly. Problem 2. I'm assuming only events that get routed through the scheduler should be candidates for being relayed to child zones. Currently, these are only volume/create_volume() and compute/create_instance(). 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? Q2. If I do "instance-list", do I have to search all zones again? Seems impractical if *every* command has to do a zone search every time. 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. Yes, there is a potential race-condition if the zone changes radically in the time between operations. But anything could happen during that time, so it has to be anticipated. In this case the user should just start again at Step-A. Also, this approach: * keeps the code clean/small * solves problem 1 Thoughts? -S Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com, and delete the original message. Your cooperation is appreciated.
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
