Hi folks, <div><br></div><div>I'd like to go back in this thread to the terminology discussion.</div><div>There we mentioned agents and drivers and you said<b> "</b><span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif"><b>a plugin which directly dispatches commands to drivers, rather than relying on agents".</b> Also, </span><span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">I think in some of discussions "plugin" was considered to implement API for one kind of device only, therefore that "multiple coexisting plugins" problem.</span></div>

<div><span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">Such considerations greatly affect the whole architecture of plugin as well as some important implementation details.</span></div>
<div><font color="#222222" face="arial, sans-serif"><br></font></div><div><font color="#222222" face="arial, sans-serif">Let me explain why it is important:</font></div><div><font color="#222222" face="arial, sans-serif"><br>

</font></div><div><font color="#222222" face="arial, sans-serif">1. That defines relationship between plugin and device types. </font></div><div><font color="#222222" face="arial, sans-serif">Option (a): </font></div><div>

<font color="#222222" face="arial, sans-serif">   we have several plugins implementing same LBaaS API where each plugin talks to it's device type via driver.</font></div><div><font color="#222222" face="arial, sans-serif">   That approach creates more complicated routing problem where you need to know the type of device to route the call to the proper plugin.</font></div>

<div><font color="#222222" face="arial, sans-serif">Option (b):</font></div><div><font color="#222222" face="arial, sans-serif">   we have one plugin and several drivers. LBaaS picks a driver depending on a type of device to which logical object is bound (VIP, Pool, etc)</font></div>

<div><font color="#222222" face="arial, sans-serif">   That approach avoids any additional call dispatching, e.g. nothing else should be done except for specifying a controller for a REST call, which is LBaaS plugin itself.</font></div>

<div><font color="#222222" face="arial, sans-serif"><br></font></div><div><font color="#222222" face="arial, sans-serif">2. Whether to have an agent.</font></div><div><font color="#222222" face="arial, sans-serif">Option (a):</font></div>

<div><font color="#222222" face="arial, sans-serif">   LBaaS plugin(s) talk directly to drivers, e.g. make synchronous calls.</font></div><div><font color="#222222" face="arial, sans-serif">   That may create additional complexity on plugin side because we need to reply asynchronously to REST calls while device operations remain synchronous. That will require additional mechanisms such as queuing synchronous calls, separate thread to handle calls from the queue, etc</font></div>

<div><font color="#222222" face="arial, sans-serif"><br></font></div><div><font color="#222222" face="arial, sans-serif">Option (b):</font></div><div><font color="#222222" face="arial, sans-serif">   LBaaS plugin talk with LBaaS agent via mq. Agent uses appropriate driver to perform device operations, upon completion it sends message back to queue. That's not only goes inline with what other plugins do but also moves complexity from plugin to agent, which is dedicated for such king of tasks.<br>

</font><br><div class="gmail_quote">My choices (1.b, 2.b) is based on current Mirantis LBaaS implementation which can be easily mapped on three typical entities of Quantum:</div></div><div class="gmail_quote">- extension for LBaaS REST API</div>
<div class="gmail_quote">- plugin (LBaaS core) - for DB functionality, device scheduling, interaction with agent</div><div class="gmail_quote">- agent - awaits commands from the plugin and applies them to devices using drivers.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">Some answers to Sasha's questions:</div><div class="gmail_quote"><b>> <span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:Calibri,sans-serif;font-size:14px">I am also looking forward to the answer regarding the semantics of associating "service" to (logical) "router".</span></b></div>
<div class="gmail_quote"><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:Calibri,sans-serif;font-size:14px">We discussed this with Salvatore. It appears that this is needed for the tenant to provide LBaaS information about which kind of service (in our case, which kind of LB) it is looking for. </span></div>
<div class="gmail_quote"><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:Calibri,sans-serif;font-size:14px">E.g. tenant would specify router_id in LB-related calls and this will allow LBaaS extract LB type from (router, service type) association and schedule proper device. It also means that for each kind of LB we need to have logical router with corresponding association.</span></div>
<div class="gmail_quote"><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:Calibri,sans-serif;font-size:14px">The only question left - why do we need to use the notion of router at all? Could tenant directly specify device type (or service type) when requesting a service?</span></div>
<div class="gmail_quote"><br></div><div class="gmail_quote"><b>> <span style="color:rgb(0,127,0);font-family:Calibri,sans-serif;font-size:14px;background-color:rgb(255,255,255)">was the intention that agent would expose "device_type" APIs (service resource abstraction) and drivers would map that to "device_type</span><span style="color:rgb(0,127,0);font-family:Calibri,sans-serif;font-size:14px;background-color:rgb(255,255,255);font-style:italic">_</span><span style="color:rgb(0,127,0);font-family:Calibri,sans-serif;font-size:14px;background-color:rgb(255,255,255)">vendor" API?</span></b></div>
<div class="gmail_quote"><span style="color:rgb(34,34,34);font-family:Calibri,sans-serif;font-size:14px;background-color:rgb(255,255,255)">I can say for current LBaaS implementation: device drivers implement the same public API which is "least common denominator" of several device-specific APIs. Additional features may be implemented as different "extra" fields in REST calls/DB and functions around them.</span></div>
<div class="gmail_quote"><span style="color:rgb(34,34,34);font-family:Calibri,sans-serif;font-size:14px;background-color:rgb(255,255,255)">So the bottom line is that API (extension, plugin, agent) is the same for any kind of devices but yet some extensibility is possible with those "extra"'s</span></div>
<div class="gmail_quote"><span style="color:rgb(34,34,34);font-family:Calibri,sans-serif;font-size:14px;background-color:rgb(255,255,255)">I think it is reasonable approach and we should apply it for LBaaS plugin.</span></div>
<div class="gmail_quote"><br></div><div class="gmail_quote"><b>> <span style="background-color:rgb(255,255,255);color:rgb(0,127,0);font-family:Calibri,sans-serif;font-size:14px">If "multi plugin" approach is chosen,  with each plugin having its own db (per definition above), it becomes extremely important to have some way for plugins to have coherently manage resources that may have their representations reside in both dbs. </span></b><span style="background-color:rgb(255,255,255);color:rgb(0,127,0);font-family:Calibri,sans-serif;font-size:14px"> </span><span style="background-color:rgb(255,255,255);color:rgb(0,127,0);font-family:Calibri,sans-serif;font-size:14px"><b>( Say "port" in core API is sort of extended in LBaaS as "pool member" - I.e. Adding/deleting the port impacts obviously pool member). Is this a valid concern? </b></span></div>
<div class="gmail_quote"><font color="#222222" face="Calibri, sans-serif"><span style="font-size:14px">That's a good question. Deleting port could effectively disable a pool member while LBaaS will not know about it. </span></font></div>
<div class="gmail_quote"><span style="font-size:14px;color:rgb(34,34,34);font-family:Calibri,sans-serif">We can think of some kind of NotifierAPI for such cases: plugins will subscribe to core resource changes and make corresponding changes in their DBs as well as changes in affected device configurations.</span></div>
<div class="gmail_quote"><span style="font-size:14px;color:rgb(34,34,34);font-family:Calibri,sans-serif"><br></span></div><div class="gmail_quote"><b><span style="font-size:14px;color:rgb(34,34,34);font-family:Calibri,sans-serif">> </span><span style="background-color:rgb(255,255,255);color:rgb(0,127,0);font-family:Calibri,sans-serif;font-size:14px">Is is viable to have these different service implementations "advertise" properties  of that implementation, via an attribute (TBD) of the service object (VIF in case of LBaaS) so that tenant uses that information to chose implementation? In other words, choosing that property of the "service" object indicates the hint as to which implementation to use.</span></b></div>
<div class="gmail_quote"><font color="#222222" face="Calibri, sans-serif"><span style="font-size:14px">In current LBaaS implementation such hint could be: balancing algorithm, requested throughput, etc.</span></font></div>
<div class="gmail_quote"><font color="#222222" face="Calibri, sans-serif"><span style="font-size:14px">These properties indirectly specify particular device type and some of them could point to specific device of the same type (less loaded, cheapest, etc).</span></font></div>
<div class="gmail_quote"><font color="#222222" face="Calibri, sans-serif"><span style="font-size:14px"><br></span></font></div><div class="gmail_quote"><br></div><div class="gmail_quote"><font color="#222222" face="Calibri, sans-serif"><span style="font-size:14px">Looking forward to your feedback as I see </span></font><span style="color:rgb(34,34,34);font-family:Calibri,sans-serif;font-size:14px">there are still some uncovered points of "service insertion" both on logical side and on code architecture side.</span></div>
<div class="gmail_quote"><font color="#222222" face="Calibri, sans-serif"><span style="font-size:14px"><br></span></font></div><div class="gmail_quote"><font color="#222222" face="Calibri, sans-serif"><span style="font-size:14px">Thanks,</span></font></div>
<div class="gmail_quote"><font color="#222222" face="Calibri, sans-serif"><span style="font-size:14px">Eugene.</span></font></div>