Hi, Pattabi,<br><br>Yes, it's better to wait for the summit prior to implementing device drivers.<div>It's seems that there will be two major approaches competing, which probably would require different versions of lbaas plugin.</div>
<div><br></div><div>Currently regular lbaas meetings are not held. </div><div>I think it will change after the summit as the direction for the further service development will be set.</div><div><br></div><div><i>> <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">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></div>
<div><font color="#222222" face="arial, sans-serif">Current "reference implementation" is focused on HAProxy and does not directly support pluggable device drivers.</font></div><div><font color="#222222" face="arial, sans-serif">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.</font></div>
<div><font color="#222222" face="arial, sans-serif"><br></font></div><div><font color="#222222" face="arial, sans-serif">Thanks,</font></div><div><font color="#222222" face="arial, sans-serif">Eugene.</font></div><div><div>
<br></div><div><div class="gmail_quote">On Fri, Mar 29, 2013 at 7:24 AM, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">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.<br>
<br>
</div>Awesome! Happy to know that you've done that.<br>
<div class="im"><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?<br>
<br>
</div>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!<br>
<div class="HOEnZb"><div class="h5"><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><br>
</div></div></blockquote></div><br></div></div>