<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 10, 2014 at 4:12 AM, Tyagi, Ishant <span dir="ltr"><<a href="mailto:ishant.tyagi@hp.com" target="_blank">ishant.tyagi@hp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">Thanks Angus for your comments.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">Your design is almost same as this one. I also agree that only engine should have DB access will DB rpc api’s. I will update the diagrams with this change.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">Regarding the worker communicating with the observer, flow would be like this:<u></u><u></u></span></p>
<p><u></u><span style="font-size:11pt;font-family:Symbol;color:rgb(31,73,125)"><span>·<span style="font:7pt "Times New Roman"">        
</span></span></span><u></u><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">Engine tells worker to create or update a resource.<u></u><u></u></span></p>
<p><u></u><span style="font-size:11pt;font-family:Symbol;color:rgb(31,73,125)"><span>·<span style="font:7pt "Times New Roman"">        
</span></span></span><u></u><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">Worker then just calls resource plugin  handle_create / handle_update etc and calls observer rpc api to observer the resource ( check_create_complete
 ) and then exits.<u></u><u></u></span></p>
<p><u></u><span style="font-size:11pt;font-family:Symbol;color:rgb(31,73,125)"><span>·<span style="font:7pt "Times New Roman"">        
</span></span></span><u></u><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">Observer then checks the resource status until it comes to the desired state.<u></u><u></u></span></p>
<p><u></u><span style="font-size:11pt;font-family:Symbol;color:rgb(31,73,125)"><span>·<span style="font:7pt "Times New Roman"">        
</span></span></span><u></u><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">Main engine then gets back the notification from observer and then schedule next parent resource to converge.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">If observer and worker are independent entities then who will invoke observer to check resource state ?</span></p></div></div></blockquote><div><br></div><div>We could do what we do for autoscaling, tag each resource's metadata with the heat stack id.<br><a href="https://github.com/openstack/heat/blob/master/heat/engine/resources/autoscaling.py#L262-L273">https://github.com/openstack/heat/blob/master/heat/engine/resources/autoscaling.py#L262-L273</a><br><br>Then the observer never needs to be told anything as it would look for notifications that have "heat-stack-id" as  a key in the metadata <br>and know it's associated with a heat stack, then it retrieves what ever other info it needs and sends an update to heat-engine (via rpc).<br><br></div><div>-Angus<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div link="blue" vlink="purple" lang="EN-US"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">-Ishant<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"><u></u><u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:"Calibri","sans-serif"">From:</span></b><span style="font-size:11pt;font-family:"Calibri","sans-serif""> Angus Salkeld [mailto:<a href="mailto:asalkeld@mirantis.com" target="_blank">asalkeld@mirantis.com</a>]
<br>
<b>Sent:</b> Tuesday, September 9, 2014 5:45 AM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Heat] convergence flow diagrams<u></u><u></u></span></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">On Mon, Sep 8, 2014 at 11:22 PM, Tyagi, Ishant <<a href="mailto:ishant.tyagi@hp.com" target="_blank">ishant.tyagi@hp.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:-moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">Hi All,<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">As per the
<span style="color:black">heat mid cycle meetup whiteboard, we have created the flowchart and sequence diagram for the convergence . Can you please review these diagrams and provide your feedback?</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:black"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:black"><a href="https://www.dropbox.com/sh/i8qbjtgfdxn4zx4/AAC6J-Nps8J12TzfuCut49ioa?dl=0" target="_blank">https://www.dropbox.com/sh/i8qbjtgfdxn4zx4/AAC6J-Nps8J12TzfuCut49ioa?dl=0</a></span><u></u><u></u></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt">Great! Good to see something.<br>
<br>
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">I was expecting something like:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">engine ~= like nova-conductor (it's the only process that talks to the db - make upgrading easier)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">observer - purely gets the actual state/properties and writes then to the db (via engine)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">worker - has a "job" queue and grinds away at running those (resource actions)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Then engine then "triggers" on differences on goal vs. actual state and create a job and sends it to the job queue.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">- so, on create it sees there is no actual state so it sends a create job for the first resource to the worker queue<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">- when the observer writes the new state for that resource it triggers the next resource create in the dependency tree.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">- like any system that relies on notifications we need timeouts and each stack needs a periodic "notification" to make sure<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">  that progress is been made or notify the user that no progress is being made.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">One question about the observer (in either my setup or the one in the diagram).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">- If we are relying on rpc notifications all the observer processes will receive a copy of the same notification<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">  (say nova create end) how are we going to decide on which one does anything with it?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">  We don't want 10 observers getting more detailed info from nova and then writing to the db<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">In your diagram worker is communicating with observer, which seems odd to me. I thought observer and worker were very<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">independent entities.<span style="color:rgb(31,73,125)">                                                                                                                                     
</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">In my setup there are less API to worry about too:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">- RPC api for the engine (access to the db)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">- RPC api for sending a job to the worker<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">- the plugin API<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt">- the observer might need an api just for the engine to tell it to start/stop observing a stack<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">-Angus<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:-moz-use-text-color -moz-use-text-color -moz-use-text-color rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><span style="color:black"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:black">Thanks,</span><u></u><u></u></p>
<p class="MsoNormal"><span style="color:black">Ishant</span><u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12pt"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div></div></div>
</div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>