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....@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace....@lists.launchpad.net] on behalf of Monsyne Dragon [mdra...@rackspace.com] 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 ab...@rackspace.com<mailto:ab...@rackspace.com>, and delete the original message. Your cooperation is appreciated. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net> 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 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
