<div>Some reasons why LBaaS core should be responsible for processing requests asynchronously: </div><ul><li>Driver code will be as simple as possible, in most cases it will just translate LBaaS model into device-specific;</li>
<li>There will be no dependencies between drivers and user requests will take approximately the same time for different drivers. This will avoid a case when some driver take too much time to apply config synchronously and block other requests.</li>
<li>REST API is already asynchronous. <br></li></ul><div>To summarize what Eugene proposed, LBaaS will consist of (see diagram <a href="http://wiki.openstack.org/Quantum/LBaaS/Architecture?action=AttachFile&do=view&target=lbaas_architecture_new.png" target="_blank">http://wiki.openstack.org/Quantum/LBaaS/Architecture?action=AttachFile&do=view&target=lbaas_architecture_new.png</a>): </div>
<ul><li>Extension - it's a front-end of a service</li><li>Plugin - responsible for request processing, persistence and core functionality (scheduling). All operations may be thought as atomic and quick. They are done synchronously.</li>
<li>Agent - responsible for executing commands on specific devices with help of drivers. It gets requests from Plugin via MQ and process them in asynchronous way</li><li>Driver - translates from unified API to vendor-specific. Its work may be time-consuming.</li>
</ul><div><ul>
</ul><div>Among all operations, update look the most complicated; the case of 2 concurrent updates and workflow is shown on <a href="http://wiki.openstack.org/Quantum/LBaaS/Architecture/ConcurrentRequests">http://wiki.openstack.org/Quantum/LBaaS/Architecture/ConcurrentRequests</a>. </div>
<div><br></div><div>Thanks,</div><div>Ilya</div><br><div class="gmail_quote">2012/11/13 Youcef Laribi <span dir="ltr"><<a href="mailto:Youcef.Laribi@eu.citrix.com" target="_blank">Youcef.Laribi@eu.citrix.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Eugene,</span></p><p class="MsoNormal">
<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Another way to look at the workflow is to make sure that the LBaaS Plugin updates the database synchronously (and generates the resource ID before returning to the user), and then let it to the driver implementations to decide whether they want to handle the call synchronously or asynchronously.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I like drawing pictures to avoid misunderstandings, so here are 2 pictures illustrating 2 vendors, one deciding to implement their driver in a synchronous way, and the other one in an asynchronous way. </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Synchronous driver implementation: </span><a href="http://wiki.openstack.org/Quantum/LBaaS?action=AttachFile&do=view&target=LBaaS+synchronous+driver+implementation.png" target="_blank">http://wiki.openstack.org/Quantum/LBaaS?action=AttachFile&do=view&target=LBaaS+synchronous+driver+implementation.png</a></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Asynchronous driver implementation: </span><a href="http://wiki.openstack.org/Quantum/LBaaS?action=AttachFile&do=view&target=LBaaS+asynchronous+driver+implementation.png" target="_blank">http://wiki.openstack.org/Quantum/LBaaS?action=AttachFile&do=view&target=LBaaS+asynchronous+driver+implementation.png</a></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">As far as the plugin is concerned, the calls to drivers are always synchronous in the sense that the driver doesn’t have to deal with queues, etc. The plugin should expect the driver to return either a “COMPLETED” status (meaning the call has been executed on the device), ora “PENDING” status (meaning that the driver has started the operation but it is not complete). The plugin updates the database in both cases with the outcome of the call, and returns the result to the user. </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">This would allow a lot of freedom in driver implementations. A vendor can start with a synchronous implementation because it is quick to implement, and then later on move on to an asynchronous implementation without impacting the LBaaS plugin. Or it can implement some calls synchronously while other calls (which might take a long time to complete) asynchronously. You can also have different vendors using different driver strategies wrt. Synchronicity, or using different queuing mechanisms.</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Thanks</span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Youcef</span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></p><p class="MsoNormal"><a name="13afa61ba5fb651b_13afa501394d9ae2_13af63d9e06e6751__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span></a></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Eugene Nikanorov [mailto:<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>] <br>
<b>Sent:</b> Monday, November 12, 2012 6:24 AM<br><b>To:</b> <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br><b>Subject:</b> [openstack-dev] [Quantum][LBaaS] Architecture: Agents, Drivers, async calls</span></p>
<div><div><p class="MsoNormal"> </p><p class="MsoNormal">Hi folks,</p><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">In the latest meeting we've mentioned several important architectural points including:</p>
</div><div><p class="MsoNormal">- agents vs direct driver call</p></div><div><p class="MsoNormal">- asynchronous execution</p></div><div><p class="MsoNormal">- dispatching a generic REST call to a proper driver.</p>
</div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">I would like to present how Mirantis team sees this based on our previous experience with LBaaS and other openstack components.</p>
</div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">We need asynchronous execution in the sense that client gets immediate response while actual device configuration happens later.</p>
</div><div><p class="MsoNormal">Workflow of such operation could look like following:</p></div><div><p class="MsoNormal">1) client makes REST call; receives an object it has created/modified with PENDING status </p>
</div><div><p class="MsoNormal">2) call is dispatched to a plugin, plugin creates/modifies/etc an object in the database</p></div><div><p class="MsoNormal">3) plugin calls driver to apply new configuration to specific device</p>
</div><div><p class="MsoNormal">4) driver finishes applying configuration, plugin updates DB object</p></div><div><p class="MsoNormal">5) client polls objectID and gets final status of operation.</p>
</div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">Now depending on approach we take, (3) could expand into different sequence of operations.</p></div><div><p class="MsoNormal">
One of the good options to choose could be using agent between plugin and drivers. In this case (3) expands to:</p></div><div><p class="MsoNormal">3.1 plugin posts message to mq</p></div><div>
<p class="MsoNormal">
3.2. message is consumed by one of the running service agents</p></div><div><p class="MsoNormal">3.3. agent calls corresponding driver directly in synchronous way.</p></div><div><p class="MsoNormal">
3.4. agent posts message upon completion.</p></div><div><p class="MsoNormal">3.5. plugin consumes the message and updates DB object with final status</p></div><div><p class="MsoNormal"> </p>
</div><div><p class="MsoNormal">Such approach solves at least two potential problems:</p></div><div><p class="MsoNormal">1. plugin may be simplified since it is not required to implement call/work item queuing </p>
</div><div><p class="MsoNormal">2. Applying device configuration is time consuming task which could take seconds. </p></div><div><p class="MsoNormal">Both plugin and agent has thread limit for any concurrent operations. </p>
</div><div><p class="MsoNormal">Handling heavy workload in large deployments will be simple with several agents consuming messages from mq.</p></div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">
Also this allows to create synchronous drivers since asyncness will be handled by mq + agent.</p></div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">Another option could be calling drivers directly without any asyncness at all while preserving above workflow (1-5). </p>
</div><div><p class="MsoNormal">That could work as temporary fast solution while allowing to split it to "plugin + agent approach" relatively easily.</p></div><div><p class="MsoNormal"> </p>
</div><div><p class="MsoNormal">Regarding the dispatching REST calls to proper driver:</p></div><div><p class="MsoNormal">In fact, VIP object should contain reference to particular device it is created at. </p>
</div><div><p class="MsoNormal"><a href="http://wiki.openstack.org/LBaaS/CoreResourceModel/proposal" target="_blank">http://wiki.openstack.org/LBaaS/CoreResourceModel/proposal</a> misses that device management part, I think it was just implied there.</p>
</div><div><p class="MsoNormal">Every balancer-related object references the VIP and hence references the specific device where it was created. </p></div><div><p class="MsoNormal">E,g, when a call for any object is made, plugin needs to extract device type from DB following those references and later plugin or agent will use it to call particular driver.</p>
</div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">Thanks,</p></div><div><p class="MsoNormal">Eugene.</p></div></div></div></div></div><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><br>
<br></blockquote></div><br>
</div>