Hi Youcef,<div><br></div><div>The picture you've made is quite accurate. </div><div>My opinion is that we should adopt the same approach for lbaas, e.g. extension - plugin - agent - drivers.</div><div><br></div><div>Thanks,</div>
<div>Eugene.<br><br><div class="gmail_quote">On Fri, Nov 2, 2012 at 10:44 AM, Youcef Laribi <span dir="ltr"><<a href="mailto:Youcef.Laribi@eu.citrix.com" target="_blank">Youcef.Laribi@eu.citrix.com</a>></span> wrote:<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, Salvatore,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">In order to clarify the terminology in our meetings and not get confused, I’m trying to draw a picture that represents how Quantum is organized today (mostly for myself). I have uploaded an attempt here:<u></u><u></u></span></p>
<p class="MsoNormal"><a href="http://wiki.openstack.org/Quantum/LBaaS?action=AttachFile&do=view&target=Quantum+Internal+components.png" target="_blank">http://wiki.openstack.org/Quantum/LBaaS?action=AttachFile&do=view&target=Quantum+Internal+components.png</a><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Can you please check it for accuracy since you are familiar with the code? Once we agree and understand this picture, we can more easily discuss what needs to be changed in Quantum to accommodate LBaaS.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Youcef<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></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> Wednesday, October 31, 2012 6:32 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] Advanced Services Insertion<u></u><u></u></span></p>
<div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Hi Salvatore,<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">I'd like to give some feedback/questions based on yesterday's meeting discussion and your renewed <a href="http://wiki.openstack.org/Quantum/ServiceInsertion" target="_blank">http://wiki.openstack.org/Quantum/ServiceInsertion</a> page.<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">First of all, I think it's worth to fix the terminology just to avoid any confusion:<u></u><u></u></p></div><div><p class="MsoNormal">
<u></u> <u></u></p></div><div><p class="MsoNormal">- extension (API extension) - set of REST calls<u></u><u></u></p></div><div><p class="MsoNormal">- plugin - code that implements certain API, works with quantum database, pushes calls to agents<u></u><u></u></p>
</div><div><p class="MsoNormal">- core plugin - code that implements core API (networks, subnets, ports, L3)<u></u><u></u></p></div><div><p class="MsoNormal">- agent - listens to commands from plugin, applies configuration to particular device type, ex: ovs agent, L3 agent<u></u><u></u></p>
</div><div><p class="MsoNormal">- driver - code that applies conf to particular device type. That is just another layer needed to support different device types. Example: Loadbalancing agent may have several drivers to talk to different LB devices.<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Some thoughts on the Service Insertion proposal:<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">
1. It seems that multiplugin approach is the right way to move further compared to "mixin" approach where we inject and modify code of the core plugin.<u></u><u></u></p></div><div><p class="MsoNormal">This will preserve plugin independency while require some changes to infrastructure (plugin loading, extension management).<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">2. Having several implementations of the same service type.<u></u><u></u></p></div><div><p class="MsoNormal">If all services of the certain type implement the same calls, then something should allow to route the call to particular plugin.<u></u><u></u></p>
</div><div><p class="MsoNormal">The options include:<u></u><u></u></p></div><div><p class="MsoNormal"> 1) passing particular service impl as a url parameter<u></u><u></u></p></div><div><p class="MsoNormal"> 2) having a prefix in uri for certain svc type: /lb_svc/lbaas_impl1/call.json, /lb_svc/lbaas_impl2/call.json<u></u><u></u></p>
</div><div><p class="MsoNormal"> 3) having (tenant, service implementation) assosiation in DB that will allow to route a call automatically. But this makes 1 to 1 relation, e.g. tenant will have only 1 impl of service available<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">My preference is (2): first of all, it "splits" whole API between core API and Adv Svc API, and also does so for different service type implementations.<u></u><u></u></p>
</div><div><p class="MsoNormal">Although URIs may not be so short as we want them, that could prevent from naming collisions between different service types.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p>
</div><div><p class="MsoNormal">3. Service Insertion:<u></u><u></u></p></div><div><p class="MsoNormal">I was thinking about routed/floating-mode insertion and there is a certain thing I don't understand: the workflow.<u></u><u></u></p>
</div><div><p class="MsoNormal">It seems that the whole thing is somehow close to what we used to call "device management" in mirantis implementaion of lbaas, but it doesn't look like solving all device management tasks.<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">So in our implementation of LBaaS the workflow was as following:<u></u><u></u></p></div><div><p class="MsoNormal">1) admin creates the device. Essentially it's just an instruction to LBaaS of where is the device (it's address), which type is it and credentials to manage it.<u></u><u></u></p>
</div><div><p class="MsoNormal">2) tenant creates VIP. During this operation LBaaS chooses the most appropriate device from the list of available and makes appropriate device configuration<u></u><u></u></p></div><div><p class="MsoNormal">
<u></u> <u></u></p></div><div><p class="MsoNormal">If we're talking about workflow within Quantum it could look like following (scenario 1 - shared HW device):<u></u><u></u></p></div><div><p class="MsoNormal">1) admin creates the device. The same as in lbaas - address, type, credentials<u></u><u></u></p>
</div><div><p class="MsoNormal">2) tenant creates VIP: Quantum LBaaS plugin chooses the device, configures connectivity between the device and tenant network (possibly with l3 router configuration), <u></u><u></u></p></div>
<div><p class="MsoNormal">configures loadbalancer according to provided VIP parameters, possibly assigns floating IP from external network<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">
If we're talking about private balancer with Quantum, then:<u></u><u></u></p></div><div><p class="MsoNormal">1) tenant creates the device. This could be a launch of VM with HA Proxy within tenant for instance.<u></u><u></u></p>
</div><div><p class="MsoNormal">2) tenant creates VIP: LBaaS configures loadbalancer according to provided VIP parameters, possibly assigns floating IP from external network. No other actions required<u></u><u></u></p></div>
<div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">It would be great if you explain how service assignments for routers maps to device management scenarios and what exact workflow will be. <u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Thanks,<u></u><u></u></p></div><div><p class="MsoNormal">Eugene.<u></u><u></u></p></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>