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>