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 

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



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 
If you receive this transmission in error, please notify us immediately by 
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

Reply via email to