<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks Eugene for the update. I am looking forward to the Open Stack Summit Design Discussions.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><br>Regards,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Pattabi<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></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:enikanorov@mirantis.com] <br><b>Sent:</b> Thursday, March 28, 2013 11:10 PM<br><b>To:</b> OpenStack Development Mailing List<br><b>Subject:</b> Re: [openstack-dev] [Quantum][LBaaS]- - LBaaS Extension in Quantum Plugin<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Hi, Pattabi,<br><br>Yes, it's better to wait for the summit prior to implementing device drivers.<o:p></o:p></p><div><p class=MsoNormal>It's seems that there will be two major approaches competing, which probably would require different versions of lbaas plugin.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Currently regular lbaas meetings are not held. <o:p></o:p></p></div><div><p class=MsoNormal>I think it will change after the summit as the direction for the further service development will be set.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><i>> </i><i><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#222222;background:white'>Any detailed clarification on where we stand on supporting LBaaS in Quantum for Grizzly and what should the vendors do for the vendor specific drivers would greatly help in planning.</span></i><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-family:"Arial","sans-serif";color:#222222'>Current "reference implementation" is focused on HAProxy and does not directly support pluggable device drivers.</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-family:"Arial","sans-serif";color:#222222'>In theory, vendor could implement it's device-specific agent the same way it's implemented for HAProxy, but i think it's better to wait until pluggable drivers support is introduced. All these design questions will be discussed at summit.</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-family:"Arial","sans-serif";color:#222222'>Thanks,</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-family:"Arial","sans-serif";color:#222222'>Eugene.</span><o:p></o:p></p></div><div><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><p class=MsoNormal>On Fri, Mar 29, 2013 at 7:24 AM, Monty Taylor <<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>> wrote:<o:p></o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'>On 03/28/2013 11:14 PM, Pattabi Ayyasami wrote:<br>><br>> Hi Eugene and All,<br>><br>> I just happened to notice this email thread in my digest. Sorry for<br>> the late query on this. I am kinda lost on this. Please help me<br>> understand.<br>><br>><br>> My team is currently working on providing the Brocade LBaaS Driver.<br>> We currently have implemented the Driver as per the Driver APIs and<br>> installing the patch as per <a href="https://review.openstack.org/#/c/20579" target="_blank">https://review.openstack.org/#/c/20579</a> on<br>> top of the Quantum Code base and validated the functionality<br>> end-to-end using the Quantum CLIs for the LBaaS as per<br>> <a href="https://wiki.openstack.org/wiki/Quantum/LBaaS/CLI" target="_blank">https://wiki.openstack.org/wiki/Quantum/LBaaS/CLI</a>. FYI, our Brocade<br>> Load Balancer is currently h/w based.<o:p></o:p></p></div><p class=MsoNormal>Awesome! Happy to know that you've done that.<o:p></o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'><br>> Now, I see that <a href="https://review.openstack.org/#/c/20579" target="_blank">https://review.openstack.org/#/c/20579</a> review is<br>> abandoned. What does it mean now? Driver framework code as suggested<br>> by <a href="https://review.openstack.org/#/c/20579" target="_blank">https://review.openstack.org/#/c/20579</a> is no longer applicable?<br>> Should we now wait for summit to discuss further on the next steps<br>> for the vendors to integrate their drivers?<o:p></o:p></p></div><p class=MsoNormal>Our system automatically abandons patches with negative reviews after a<br>week so that we don't keep a lot of cruft around. In this case though,<br>Dan just put a -2 on the review to prevent it from accidentally getting<br>merged before we open up development for havana again. As soon as havana<br>is open, we can restore that patch and work on getting it applied - so<br>no need to worry!<o:p></o:p></p><div><div><p class=MsoNormal><br>> Also, I would like to be part of the weekly meetings on LBaaS and<br>> where can I find the meeting details?<br>><br>> Any detailed clarification on where we stand on supporting LBaaS in<br>> Quantum for Grizzly and what should the vendors do for the vendor<br>> specific drivers would greatly help in planning .<br>><br>> Thanks. Pattabi<br>><br>> =====================================================================<br>><br>><br>Sure. Let us plan again to make it happen in forth coming releases.<br>><br>> Thanks Anand<br>><br>> On Mar 14, 2013, at 8:30 AM, "Eugene Nikanorov"<br>> <<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a><mailto:<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>>> wrote:<br>><br>> Hi Anand,<br>><br>> Unfortunately support for all kinds of LB devices or even driver<br>> framework for such support appeared to be pretty large feature that<br>> has put too much reviewing/testing load on quantum's core development<br>> team. So they proposed alternative solution which is much simpler but<br>> supports only process-on-host approach. I think all that we've<br>> discussed was not discarded though. But obviously feature-rich LBaaS<br>> implementation is moved to the next release cycle.<br>><br>> By the way, we've got code that implements initially proposed<br>> approach (as described on the wiki) so I hope we'll get it merged in<br>> Havana much sooner. That could allow us to move forward with<br>> developing advanced features like service types, routed LB insertion,<br>> etc.<br>><br>> Thanks, Eugene.<br>><br>><br>><br>> On Thu, Mar 14, 2013 at 7:06 PM, Palanisamy, Anand<br>> <<a href="mailto:apalanisamy@paypal.com">apalanisamy@paypal.com</a><mailto:<a href="mailto:apalanisamy@paypal.com">apalanisamy@paypal.com</a>>> wrote:<br>> Eugene,<br>><br>> First of all, I was surprised that we do not have any support for h/w<br>> LBs and VIrtual LBs.<br>><br>> Now, we badly get into Architecture discussion again for addressing<br>> all these concerns before we go for the summit.<br>><br>> Pls let me know suggestions/comments.<br>><br>> Thanks Anand<br>><br>> On Mar 14, 2013, at 7:54 AM, "Eugene Nikanorov"<br>> <<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a><mailto:<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>>> wrote:<br>><br>> I'm afraid there's no detailed description for grizzly lbaas<br>> architecture right now.<br>>> So, is this similar to current L3_Agent daemon we have in Quantum<br>>> for Folsom release?<br>> Correct.<br>><br>>> As well the confusion is like the general Plug-in and Agent<br>>> architecture [similar to OVS], we have in OS is like Plug-in will<br>>> be in Controller and Agent has to be on the Compute Node.<br>> Right, lbaas plugin runs within quantum-server, lbaas agent may run<br>> on network controller or on some compute node (remember that it must<br>> run on one host only)<br>><br>>> So, when we are trying for Service Insertion, do we need to have<br>>> same architecture as Plug-in and Agent above or it should be<br>>> generic in such a way that independent of underlying<br>>> Hardware/Products, We should be able to bring up services<br>> I'm not sure I understood your question. Currently quantum's lbaas<br>> plugin supports the only type of loadbalancer and it's not<br>> customizible via drivers at this point.<br>><br>> Thanks, Eugene.<br>><br>> On Thu, Mar 14, 2013 at 6:09 PM, balaji patnala<br>> <<a href="mailto:patnala003@gmail.com">patnala003@gmail.com</a><mailto:<a href="mailto:patnala003@gmail.com">patnala003@gmail.com</a>>> wrote: Hi<br>> Eugene,<br>><br>><br>>> With current lbaas implementation the link that you've provided is<br>>> not actual as current implementation has adopted different<br>>> architecture.<br>><br>> Can you point me to the links for current implementation details.<br>><br>><br>> As well the confusion is like the general Plug-in and Agent<br>> architecture [similar to OVS], we have in OS is like Plug-in will be<br>> in Controller and Agent has to be on the Compute Node.<br>><br>> So, when we are trying for Service Insertion, do we need to have same<br>> architecture as Plug-in and Agent above or it should be generic in<br>> such a way that independent of underlying Hardware/Products, We<br>> should be able to bring up services.<br>><br>>> Current implementation only supports haproxy-on-the-host solution<br>>> so it's not suitable for hardware/VM LBs.<br>><br>> So, is this similar to current L3_Agent daemon we have in Quantum for<br>> Folsom release?<br>><br>> Thanks, Balaji.P<br>><br>> On Thu, Mar 14, 2013 at 5:25 PM, Eugene Nikanorov<br>> <<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a><mailto:<a href="mailto:enikanorov@mirantis.com">enikanorov@mirantis.com</a>>> wrote: Hi<br>> Balaji,<br>><br>> With current lbaas implementation the link that you've provided is<br>> not actual as current implementation has adopted different<br>> architecture.<br>><br>>> Can you please through some light on the Agent part of the<br>>> architecture like where exactly the agent will be running like<br>>> OpenStack Controller Node or OpenStack Compute Node.?<br>> In grizzly, lbaas agent should run on some node - it could be compute<br>> node or network controller node. The only important is that there<br>> MUST be only one instance of lbaas agent running.<br>><br>> Current implementation only supports haproxy-on-the-host solution so<br>> it's not suitable for hardware/VM LBs. Support for such use case is<br>> planned in the next release.<br>><br>> Thanks, Eugene.<br>><br>> On Thu, Mar 14, 2013 at 3:46 PM, balaji patnala<br>> <<a href="mailto:patnala003@gmail.com">patnala003@gmail.com</a><mailto:<a href="mailto:patnala003@gmail.com">patnala003@gmail.com</a>>> wrote: Hi Ilya,<br>><br>> As described in the document given in the below link:<br>><br>> <a href="http://wiki.openstack.org/Quantum/LBaaS/Agent" target="_blank">http://wiki.openstack.org/Quantum/LBaaS/Agent</a><br>><br>> Agent part will be running on Compute Node or Controller Node ?.<br>><br>> I guess it should be on the Controller Node only. As the driver<br>> abstraction layer is for choosing the right driver for the device it<br>> has to connect like Driver A to the Device Type A. etc. [This<br>> approach is for HW device LB]<br>><br>> If we want to have SW-based-LB like SLB VM, does the above<br>> architecture is valid?<br>><br>> Can you please through some light on the Agent part of the<br>> architecture like where exactly the agent will be running like<br>> OpenStack Controller Node or OpenStack Compute Node.?<br>><br>> Thanks in advance.<br>><br>> Regards, Balaji.P<br>><br>> On Thu, Feb 7, 2013 at 8:26 PM, Ilya Shakhat<br>> <<a href="mailto:ishakhat@mirantis.com">ishakhat@mirantis.com</a><mailto:<a href="mailto:ishakhat@mirantis.com">ishakhat@mirantis.com</a>>> wrote: Hi<br>> Pattabi,<br>><br>> Code for LBaaS agent and driver API is on review. You may check it<br>> from Gerrit topic <a href="https://review.openstack.org/#/c/20579" target="_blank">https://review.openstack.org/#/c/20579</a>.<br>> Instructions on how to run the code in DevStack environment are at<br>> <a href="http://wiki.openstack.org/Quantum/LBaaS/Agent" target="_blank">http://wiki.openstack.org/Quantum/LBaaS/Agent</a>. Driver API is<br>> documented at <a href="http://wiki.openstack.org/Quantum/LBaaS/DriverAPI" target="_blank">http://wiki.openstack.org/Quantum/LBaaS/DriverAPI</a><br>><br>> Thanks, Ilya<br>><br>><br>> 2013/2/7 Avishay Balderman<br>> <<a href="mailto:AvishayB@radware.com">AvishayB@radware.com</a><mailto:<a href="mailto:AvishayB@radware.com">AvishayB@radware.com</a>>> The basic lbaas<br>> driver is not committed yet ? it is under review.<br>><br>> From: Pattabi Ayyasami<br>> [mailto:<a href="mailto:pattabi@Brocade.com">pattabi@Brocade.com</a><mailto:<a href="mailto:pattabi@Brocade.com">pattabi@Brocade.com</a>>] Sent:<br>> Thursday, February 07, 2013 3:06 AM To:<br>> <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>><br>><br>Subject: [openstack-dev] [Quantum][LBaaS] - LBaaS Extension in Quantum<br>Plugin<br>><br>> Hi,<br>><br>> I am in the process of adding vendor specific plugin implementation<br>> for LBaaS as a service. I have my stand alone driver ready and would<br>> like to integrate with the framework. I looked at the latest Git Hub<br>> <a href="https://github.com/openstack/quantum" target="_blank">https://github.com/openstack/quantum</a> repository. I do not find any<br>> code that allows me to hook my plugin code to the framework.<br>><br>> Really appreciate if someone could provide me any pointers on how I<br>> go about doing it.<br>><br>> Regards, Pattabi<br>><br>> ================================================================<br>><br>><br>> _______________________________________________ OpenStack-dev mailing<br>> list <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><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><o:p></o:p></p></div></div></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></body></html>