<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:宋体;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@宋体";
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:宋体;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:宋体;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin:0cm;
margin-bottom:.0001pt;
text-indent:21.0pt;
font-size:12.0pt;
font-family:宋体;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:736513023;
mso-list-type:hybrid;
mso-list-template-ids:631388976 -1813467538 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:18.0pt;
text-indent:-18.0pt;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="ZH-CN" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi,
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">I think you may have some misunderstanding on the PoC design. (the proxy node only to listen the RPC to compute-node/cinder-volume/L2/L3 agent…)<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:18.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo1">
<![if !supportLists]><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">1)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">The cascading layer including the proxy nodes are assumed running in VMs but not in physical servers (you can do that). Even in CJK intercloud
( China, Japan, Korea ) intercloud, the cascading layer including API,messagebus, DB, proxy nodes are running in VMs<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:18.0pt;text-indent:0cm"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:18.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo1">
<![if !supportLists]><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">2)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">For proxy nodes running in VMs, it's not strange that multiple proxy nodes running over one physical server. And if the load of one
proxy nodes increased, it’s easy to move VM from one physical server to another, this is quite mature technology and easy to monitor, to deal with. And most of virtualization also support hot scale-up for one virtual machine.<o:p></o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="margin-left:18.0pt;text-indent:-18.0pt;mso-list:l0 level1 lfo1">
<![if !supportLists]><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">3)<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">It's already in some scenario that the ZooKeeper is used to manage the proxy node role and membership. And backup node will take over
the responsibility of the failed node.<o:p></o:p></span></p>
<p class="MsoListParagraph"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">So I did not see that “fake node” mode will bring extra benefit. On the other hand, the “fake node” add additional complexity:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">1 ) the complexity of the code in cascade service, to implement the RPC to scheduler and the RPC to compute node/cinder volume.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">2 ) how to judge the load of a “fake node”. If all “fake-nodes” will run flatly(no special process or thread, just a symbol) in the same process,
then how can you judge the load of a “fake node”, by message number ? but message number does not imply the load. The load is often measured through CPU utilization / memory occupy, so how to calculate the load for each “fake node” and then make decision
to move which nodes to other physical server? How to manage this “fake-node” in Zookeeper like cluster ware. You may want to make fake-node run in different process or thread space, then you need to manage “fake-node” and process/thread relationship.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">I admit that the proposal 3 is much more complex to make it work for the flexible load balance. We have to record relative stamp for each message
in the queue, pick the message from message bus, and put the message into task queue for each site in DB, then execute this task in order.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">As what has been described above that the proposal 2 does not bring extra benefit, and if we don’t want to strive for the 3<sup>rd</sup> direction,
we’d better fallback to the proposal 1. <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-align:justify;text-justify:inter-ideograph"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Best Regards<o:p></o:p></span></p>
<p class="MsoNormal" style="text-align:justify;text-justify:inter-ideograph"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Chaoyi Huang ( Joe Huang )</span><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> eran@gampel.co.il [mailto:eran@gampel.co.il]
<b>On Behalf Of </b>Eran Gampel<br>
<b>Sent:</b> Thursday, August 27, 2015 7:07 PM<br>
<b>To:</b> joehuang; Irena Berezovsky; Eshed Gal-Or; Ayal Baron; OpenStack Development Mailing List (not for usage questions); caizhiyuan (A); Saggi Mizrahi; Orran Krieger; Gal Sagie; Orran Krieger; Zhipeng Huang<br>
<b>Subject:</b> Re: [openstack-dev][tricircle] multiple cascade services<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">Hi, <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Please see my comments <span style="color:red">
inline </span><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">BR,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:black">Eran </span><span lang="EN-US"><o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Hello,
</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">As what we discussed in the yesterday’s meeting, the contradict is how to scale out
cascade services.</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">1)</span><span lang="EN-US" style="font-size:7.0pt;font-family:"Times New Roman","serif";color:#1F497D">
</span><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">In PoC, one proxy node will only forward to one bottom openstack, the proxy node will be added to a regarding AZ, and multiple proxy nodes for one bottom OpenStack
is feasible by adding more proxy nodes into this AZ, and the proxy node will be scheduled like usual.
</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Is this perfect? No. Because the VM’s host attribute is binding to a specific proxy node, therefore, these multiple proxy nodes can’t
work in cluster mode, and each proxy node has to be backup by one slave node.</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:red">[Eran] I agree with this point - In the PoC you had a limitation of single active proxy per bottom site. In addition, each proxy could only
support a Single bottom site by-design.</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">2)</span><span lang="EN-US" style="font-size:7.0pt;font-family:"Times New Roman","serif";color:#1F497D">
</span><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">The fake node introduced in the cascade service.
</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Because fanout rpc call for Neutron API is assumed, then no multiple fake nodes for one bottom openstack is allowed.</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:red">[Eran] In fact, this is not a limitation in the current design. We could have multiple "fake nodes" to handle the same bottom site, but only
1 that is Active. If this Active node becomes unavailable, one of the other "Passive" nodes can take over with some leader-election or any other known design pattern (it's an implementation decision).</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">And because the traffic to one bottom OpenStack is un-predictable, and move these fake nodes dynamically among cascade service is very
complicated, therefore we can’t deploy multiple fake nodes in one cascade service.</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:8.5pt;font-family:"Calibri","sans-serif";color:red">[Eran] I'm not sure I follow you on this point... as we see it, there are 3 places where load is an issue (and potential bottleneck):</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:8.5pt;font-family:"Calibri","sans-serif";color:red">1. API + message queue + database</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:8.5pt;font-family:"Calibri","sans-serif";color:red">2. Cascading Service itself (dependency builder, communication service, DAL)</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:8.5pt;font-family:"Calibri","sans-serif";color:red">3. Task execution</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:8.5pt;font-family:"Calibri","sans-serif";color:red">I think you were concerned about #2, which in our design must be a single-active per bottom site (to maintain task order of execution). </span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:8.5pt;font-family:"Calibri","sans-serif";color:red">In our opinion, the heaviest part is actually #3 (task execution), which is delegated to a separate execution path (Mistral workflow or otherwise).</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:8.5pt;font-family:"Calibri","sans-serif";color:red">In case we have one Cascading Service handling multiple Bottom sites and at some point in time we wish to handle just one Bottom site and move
the rest of them to a different Cascading Service instance, it is possible.</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:8.5pt;font-family:"Calibri","sans-serif";color:red">The way we see it, is we have multiple Fake Nodes running in multiple Cascading Services, in Active-Passive. That way, when one Cascading
Service instance becomes overloaded, it can give up its "Leadership" on active fake nodes, and some of the other Cascading Services will take over (leader election, or otherwise). This is a very common design pattern, we don't see anything special or complicated
here.</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">At last, we have to deploy one fake node one cascade service.</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">And one cascade service one bottom openstack will limit the burst traffic to one cascade openstack.</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">And you have to backup the cascade service.</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:8.5pt;font-family:"Calibri","sans-serif";color:red">[Eran] This is correct. In the worst case of traffic burst to a single bottom site, a single Cascading Service will handle a single Fake Node
exclusively, and it is not possible to handle a single Bottom Site with more than a single Fake Node at any given time.</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:8.5pt;font-family:"Calibri","sans-serif";color:red">Having said that, we don't see a scenario where the Fake Node / Cascading Service will become a bottleneck. We think that #3 (task execution)
and #1 (message queue, API and database) will choke before, probably because the OpenStack components in the Top and Bottom sites will not be able to handle the burst (which is a completely different story).</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin-left:18.0pt"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">3)</span><span lang="EN-US" style="font-size:7.0pt;font-family:"Times New Roman","serif";color:#1F497D">
</span><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">From the beginning, I prefer to run multiple cascade service in parallel, and all of them work in load balance cluster mode.</span><span lang="EN-US"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:red">[Eran] I believe we already discussed this before - It is actually not possible. </span><span lang="EN-US"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:red">If you did that, you would have race condition and miss-ordering of actions, and an inconsistent state in the Bottom sites.</span><span lang="EN-US"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:red">For example, if the Top user did:</span><span lang="EN-US"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:red">#1 create security group "111" </span><span lang="EN-US"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:red">#2 update security group "111" with "Allow *"</span><span lang="EN-US"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:red">#3 update security group "111" with "Drop *"</span><span lang="EN-US"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:red">If you have more than a single Cascading service that is responsible for site "A", you don't know what will be the order of actions.</span><span lang="EN-US"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:red">In the example I gave, you may end up with site "A" having security group "111" with "Allow *" or with "Deny *".</span><span lang="EN-US"><o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:12.0pt">
<span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">API of (Nova, Cinder, Neutron… ) calling cascade service through RPC, and the RPC call will be only forwarded to one of the cascade service ( just put the RPC to message
bus queue, and if one of the cascade service pick up the message, the message will be remove from the queue, and will not be consumed by other cascade service ). When the cascade service received a message, will start a task to execute the request. If multiple
bottom openstacks will be involved, for example, networking, then the networking request will be forwarded to regarding multiple bottom openstack where there is resources (VM, floating IP) resides ).</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:12.0pt">
<span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:12.0pt">
<span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">To keep the correct order of operations, all tasks will store necessary data in DB to prevent the operation be broken for single site. (if a VM is creating, reboot
is not allowed, such kind of use cases has already been done on API of (Nova.Cinder,Neutron,…) side )</span><span lang="EN-US"><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:red">[Eran] This will not enforce order - Only keep state between non-racing actions. It will not guarantee consistency in common scenarios of multiple updates to a specific resource within a short period,
as I just gave with the security group.</span><span lang="EN-US"> <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:red">Maybe it will work for a few predictable use cases, but there will always be something else that you did not plan for.</span><span lang="EN-US"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:red">It is ultimately an unsafe design.</span><span lang="EN-US"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="color:red">If you propose to make the database the coordinator of this process (which I don't see how), you will end-up with an even worse bottleneck - in the database.</span><span lang="EN-US"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:12.0pt">
<span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:12.0pt">
<span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Through this way, we can dynamically add cascade service node, and balance the traffic dynamically.
</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-align:justify;text-justify:inter-ideograph">
<span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Best Regards</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-align:justify;text-justify:inter-ideograph">
<span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Chaoyi Huang ( Joe Huang )</span><span lang="EN-US"><o:p></o:p></span></p>
</div>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
</div>
</div>
</body>
</html>