openstack team mailing list archive

[Monsyne Dragon <mdragon@xxxxxxxxxxxxx>]

On 2/16/11 9:26 AM, Sandy Walsh wrote:
> 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.
Hmm.....  You wouldn't really need to re-marshall the request. Just 
copy  the needed headers & url, and pass along the body as you received 
it.  Basically you are just
acting as a sort of http proxy.

> 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.
I think just  proxying the request is cleaner. Otherwise you have two 
different ways of calling an api method.

> *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?
Basically there needs to be some notification (pub sub, rest call, 
whatever) that gets passed back up the chain to the 'higher' 
schedulers.  They use this to replicate basic info on the  higher zones 
(possibly as a cache).  This could also drive an event feed to the end 
user.

The alternative is to pull from zones and cache that.  But the 
notification approach seems  more efficient.

> Seems impractical if *every* command has to do a zone search every time.
Besides the zones having replicated info on the instances (I'm assuming 
each zone has it's own db) the instance_id's could have structure to 
them (i.e. a URI) which could indicate which zone they live in.

> 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?
Hmmm... I am not sure about exposing internal structure to customers in 
this way.  Would you really want the more 'internal' zones exposed?

> -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 abuse@xxxxxxxxxxxxx, and delete the original message.
> Your cooperation is appreciated.
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp


--

--
    -Monsyne Dragon
    work:         210-312-4190
    mobile        210-441-0965
    google voice: 210-338-0336



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 abuse@xxxxxxxxxxxxx, and delete the original message.
Your cooperation is appreciated.