Eugene,<div><br></div><div>Don't we want to follow the plugin/agent model instead of direct driver call? </div><div>plugin/agent call preserves the same semantics of other services and in addition you are riding on the coattails of the security mechanisms of mq. </div>
<div><br></div><div>How is the authentication done in the direct driver call? </div><div><br></div><div>Thanks</div><div>Vinay<br><div><br><div class="gmail_quote">On Mon, Nov 12, 2012 at 6:23 AM, Eugene Nikanorov <span dir="ltr"><<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi folks,<div><br></div><div>In the latest meeting we've mentioned several important architectural points including:</div>
<div>- agents vs direct driver call</div><div>- asynchronous execution</div><div>- dispatching a generic REST call to a proper driver.</div>
<div><br></div><div>I would like to present how Mirantis team sees this based on our previous experience with LBaaS and other openstack components.</div><div><br></div><div>We need asynchronous execution in the sense that client gets immediate response while actual device configuration happens later.</div>
<div>Workflow of such operation could look like following:</div><div>1) client makes REST call; receives an object it has created/modified with PENDING status </div><div>2) call is dispatched to a plugin, plugin creates/modifies/etc an object in the database</div>
<div>3) plugin calls driver to apply new configuration to specific device</div><div>4) driver finishes applying configuration, plugin updates DB object</div><div>5) client polls objectID and gets final status of operation.</div>
<div><br></div><div>Now depending on approach we take, (3) could expand into different sequence of operations.</div><div>One of the good options to choose could be using agent between plugin and drivers. In this case (3) expands to:</div>
<div>3.1 plugin posts message to mq</div><div>3.2. message is consumed by one of the running service agents</div><div>3.3. agent calls corresponding driver directly in synchronous way.</div><div>3.4. agent posts message upon completion.</div>
<div>3.5. plugin consumes the message and updates DB object with final status</div><div><br></div><div>Such approach solves at least two potential problems:</div><div>1. plugin may be simplified since it is not required to implement call/work item queuing </div>
<div>2. Applying device configuration is time consuming task which could take seconds. </div><div>Both plugin and agent has thread limit for any concurrent operations. </div><div>Handling heavy workload in large deployments will be simple with several agents consuming messages from mq.</div>
<div><br></div><div>Also this allows to create synchronous drivers since asyncness will be handled by mq + agent.</div><div><br></div><div>Another option could be calling drivers directly without any asyncness at all while preserving above workflow (1-5). </div>
<div>That could work as temporary fast solution while allowing to split it to "plugin + agent approach" relatively easily.</div><div><br></div><div>Regarding the dispatching REST calls to proper driver:</div><div>
In fact, VIP object should contain reference to particular device it is created at. </div>
<div><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.</div>
<div>Every balancer-related object references the VIP and hence references the specific device where it was created. </div>
<div>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.</div><div><br></div><div>Thanks,</div>
<div>
Eugene.</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><br clear="all"><div><br></div>-- <br>Vinay Bannai<br>Email: <a href="mailto:vbannai@gmail.com">vbannai@gmail.com</a><br>Google Voice: 415 938 7576<br><br>
</div></div>