<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 2/16/11 9:26 AM, Sandy Walsh wrote:
<blockquote
cite="mid:9181_1297870024_p1GFQw4H028883_60A3427EF882A54BA0A1971AE6EF038807B57C04@SAT2EXD02.RACKSPACE.CORP"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<style type="text/css" id="owaParaStyle"></style>
<div style="direction: ltr; font-family: Tahoma; color: rgb(0, 0,
0); font-size: 10pt;">Hi y'all
<div><br>
</div>
<div>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:
<div><br>
</div>
<div><b>Problem 1.</b> 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. <br>
</div>
</div>
</div>
</blockquote>
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 <br>
acting as a sort of http proxy. <br>
<br>
<blockquote
cite="mid:9181_1297870024_p1GFQw4H028883_60A3427EF882A54BA0A1971AE6EF038807B57C04@SAT2EXD02.RACKSPACE.CORP"
type="cite">
<div style="direction: ltr; font-family: Tahoma; color: rgb(0, 0,
0); font-size: 10pt;">
<div>
<div>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.</div>
<div><br>
</div>
</div>
</div>
</blockquote>
I think just proxying the request is cleaner. Otherwise you have
two different ways of calling an api method. <br>
<br>
<blockquote
cite="mid:9181_1297870024_p1GFQw4H028883_60A3427EF882A54BA0A1971AE6EF038807B57C04@SAT2EXD02.RACKSPACE.CORP"
type="cite">
<div style="direction: ltr; font-family: Tahoma; color: rgb(0, 0,
0); font-size: 10pt;">
<div>
<div>
</div>
<div><b>Problem 2.</b> 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(). </div>
<div><br>
</div>
<div>But this introduces a problem. Consider this use-case:</div>
<div><br>
</div>
<div>a. I issue a "create-instance" via the top-level API in
zone-A</div>
<div>b. the request is relayed down to zone-C</div>
<div>c. the instance is created some time later </div>
<div> 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?</div>
<div> Q2. If I do "instance-list", do I have to search all
zones again? </div>
<div><br>
</div>
</div>
</div>
</blockquote>
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. <br>
<br>
The alternative is to pull from zones and cache that. But the
notification approach seems more efficient. <br>
<br>
<blockquote
cite="mid:9181_1297870024_p1GFQw4H028883_60A3427EF882A54BA0A1971AE6EF038807B57C04@SAT2EXD02.RACKSPACE.CORP"
type="cite">
<div style="direction: ltr; font-family: Tahoma; color: rgb(0, 0,
0); font-size: 10pt;">
<div>
<div>
</div>
<div>Seems impractical if *every* command has to do a zone
search every time. <br>
</div>
</div>
</div>
</blockquote>
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. <br>
<br>
<blockquote
cite="mid:9181_1297870024_p1GFQw4H028883_60A3427EF882A54BA0A1971AE6EF038807B57C04@SAT2EXD02.RACKSPACE.CORP"
type="cite">
<div style="direction: ltr; font-family: Tahoma; color: rgb(0, 0,
0); font-size: 10pt;">
<div>
<div>One alternative is to make
Host-Best-Match/Zone-Best-Match stand-alone query
operations.</div>
<div><br>
</div>
<div>My above use-case would look like this:</div>
<div>a. I issue a "find-best-zone" command to the top-level
API in zone-A</div>
<div>b. I get an API URL to zone-C</div>
<div>c. I do my "create-instance" on zone-C, as well as all
related operations. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Also, this approach:</div>
<div>* keeps the code clean/small</div>
<div>* solves problem 1</div>
<div><br>
</div>
<div>Thoughts?</div>
<div><br>
</div>
</div>
</div>
</blockquote>
Hmmm... I am not sure about exposing internal structure to customers
in this way. Would you really want the more 'internal' zones
exposed? <br>
<br>
<blockquote
cite="mid:9181_1297870024_p1GFQw4H028883_60A3427EF882A54BA0A1971AE6EF038807B57C04@SAT2EXD02.RACKSPACE.CORP"
type="cite">
<div style="direction: ltr; font-family: Tahoma; color: rgb(0, 0,
0); font-size: 10pt;">
<div>
<div>
</div>
<div>-S<br>
<br>
</div>
</div>
</div>
<style type="text/css">embed[type*="application/x-shockwave-flash"],embed[src*=".swf"],object[type*="application/x-shockwave-flash"],object[codetype*="application/x-shockwave-flash"],object[src*=".swf"],object[codebase*="swflash.cab"],object[classid*="D27CDB6E-AE6D-11cf-96B8-444553540000"],object[classid*="d27cdb6e-ae6d-11cf-96b8-444553540000"],object[classid*="D27CDB6E-AE6D-11cf-96B8-444553540000"]{ display: none !important;}</style>
<style type="text/css">embed[type*="application/x-shockwave-flash"],embed[src*=".swf"],object[type*="application/x-shockwave-flash"],object[codetype*="application/x-shockwave-flash"],object[src*=".swf"],object[codebase*="swflash.cab"],object[classid*="D27CDB6E-AE6D-11cf-96B8-444553540000"],object[classid*="d27cdb6e-ae6d-11cf-96b8-444553540000"],object[classid*="D27CDB6E-AE6D-11cf-96B8-444553540000"]{ display: none !important;}</style>
<pre>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 <a class="moz-txt-link-abbreviated" href="mailto:abuse@rackspace.com">abuse@rackspace.com</a>, and delete the original message.
Your cooperation is appreciated.
</pre>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Mailing list: <a class="moz-txt-link-freetext" href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a>
Post to : <a class="moz-txt-link-abbreviated" href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>
Unsubscribe : <a class="moz-txt-link-freetext" href="https://launchpad.net/~openstack">https://launchpad.net/~openstack</a>
More help : <a class="moz-txt-link-freetext" href="https://help.launchpad.net/ListHelp">https://help.launchpad.net/ListHelp</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
--
-Monsyne Dragon
work: 210-312-4190
mobile 210-441-0965
google voice: 210-338-0336</pre>
<PRE>
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@rackspace.com, and delete the original message.
Your cooperation is appreciated.
</PRE></body>
</html>