openstack team mailing list archive

[Sandy Walsh <sandy.walsh@xxxxxxxxxxxxx>]

Thanks Dragon!

Had another conversation with Jay on this as well. I think the caching with the smart use of instance/customer naming will go a long way to helping the search.

More comments below ...

-S

From: openstack-bounces+sandy.walsh=rackspace.com@xxxxxxxxxxxxxxxxxxx [openstack-bounces+sandy.walsh=rackspace.com@xxxxxxxxxxxxxxxxxxx] on behalf of Monsyne Dragon [mdragon@xxxxxxxxxxxxx]

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.

Yup, that's what I was proposing. I guess I wasn't clear.
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.

Yes. The proxying will have to occur in the scheduler where the decision making is done, correct?
Problem 2.

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.
I like the notification scheme as well. We may want to revisit once that gets in place.
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.
+1
One alternative is to make Host-Best-Match/Zone-Best-Match stand-alone query operations.
My above use-case would look like this:
Hmmm... I am not sure about exposing internal structure to customers in this way.  Would you really want the more 'internal' zones exposed?

To Jay's point, the "control panel" would hide all that switching.
-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<mailto:abuse@xxxxxxxxxxxxx>, and delete the original message.
Your cooperation is appreciated.



_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx<mailto: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.