<div dir="ltr">Agree that we use polling mode to synchronize resource status, but it's a bit weird to deploy a localized service for just polling. Maybe we can define a status synchronizatioin task to handle such work so it can be done by cascade service itself. If multiple cascade service is deployed, to avoid conflict, we can utilize leader selection (provided by zookeeper and other tools) to find a leader cascade service. Leader cascade service is responsible for periodically creating status synchronization task and other members finish the task.<div><br></div><div>BR</div><div>Zhiyuan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 3 August 2015 at 14:48, joehuang <span dir="ltr"><<a href="mailto:joehuang@huawei.com" target="_blank">joehuang@huawei.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="ZH-CN" link="blue" vlink="purple">
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi,<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">In the PoC, the status synchronization is done by the proxy node running with periodic task to poll the recent changed status, for example, VM
status, volume status, and port status, etc. One proxy node will be responsible for one cascaded OpenStack instance, and configured with one user to be able to query the status. It works, although not perfect, and the controllable.
<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">During the last weekly meeting, Gampel mentioned that to have a local pluggable cascaded service for "port status" and other site-localized information
collection, and push to the top layer cascade service. I would like to know more your thoughts on the “push” method.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p style="margin-left:18.0pt">
<u></u><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>1.<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">We cannot push every status change to the top layer, especially if one site’s down and restart all service, then all object’s status
will be changed frequently in very short time, if “push” based on every status, imaging that there are lots of objects in one site, the burst API calling to the top layer will be un-controllable.<u></u><u></u></span></p>
<p style="margin-left:18.0pt;text-indent:0cm"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p style="margin-left:18.0pt">
<u></u><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">The local cascaded service has to listen on the message bus to track each status change event of all objects. It’ll work like Ceilometers
agent to capture the status change events. Not all status change will send notification even to the message bus, have to add code to each service. It’s also complex to implement.<u></u><u></u></span></p>
<p><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">To my understanding, the more viable way is to deploy a localized service, but still using polling method to get the status, and send to the up
layer in batch mode to reduce the number of API calling to the top layer.<u></u><u></u></span></p>
<p><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">In the top layer, using a task to process the status change in case of burst status refresh.<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">Best Regards<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1f497d">Chaoyi Huang ( joehuang )<u></u><u></u></span></p>
</div>
</div>
</div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>