Open Stack

Hi Eugene and All,

I just happened to notice this email thread in my digest. Sorry for the late query on this.
I am kinda lost on this.  Please help me understand.


My team is currently working on providing the Brocade LBaaS Driver. We currently have implemented the Driver as per the Driver APIs and installing the patch as per https://review.openstack.org/#/c/20579 on top of the Quantum Code base and validated the functionality end-to-end using the Quantum CLIs for the LBaaS as per https://wiki.openstack.org/wiki/Quantum/LBaaS/CLI. FYI, our Brocade Load Balancer is currently h/w based.

Now, I see that https://review.openstack.org/#/c/20579 review is abandoned.  What does it mean now? Driver framework code as suggested by https://review.openstack.org/#/c/20579 is no longer applicable?  
Should we now wait for summit to discuss further on the next steps for the vendors to integrate their drivers?

Also, I would like to be part of the weekly meetings on LBaaS and where can I find the meeting details?

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 .

Thanks.
Pattabi

=====================================================================
Sure. Let us plan again to make it happen in forth coming releases.

Thanks
Anand

On Mar 14, 2013, at 8:30 AM, "Eugene Nikanorov" <enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>> wrote:

Hi Anand,

Unfortunately support for all kinds of LB devices or even driver framework for such support appeared to be pretty large feature that has put too much reviewing/testing load on quantum's core development team.
So they proposed alternative solution which is much simpler but supports only process-on-host approach.
I think all that we've discussed was not discarded though.
But obviously feature-rich LBaaS implementation is moved to the next release cycle.

By the way, we've got code that implements initially proposed approach (as described on the wiki) so I hope we'll get it merged in Havana much sooner.
That could allow us to move forward with developing advanced features like service types, routed LB insertion, etc.

Thanks,
Eugene.



On Thu, Mar 14, 2013 at 7:06 PM, Palanisamy, Anand <apalanisamy at paypal.com<mailto:apalanisamy at paypal.com>> wrote:
Eugene,

First of all, I was surprised that we do not have any support for h/w LBs and VIrtual LBs.

Now, we badly get into Architecture discussion again for addressing all these concerns before we go for the summit.

Pls let me know suggestions/comments.

Thanks
Anand

On Mar 14, 2013, at 7:54 AM, "Eugene Nikanorov" <enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>> wrote:

I'm afraid there's no detailed description for grizzly lbaas architecture right now.
> So, is this similar to current L3_Agent daemon we have in Quantum for Folsom release?
Correct.

>As well the confusion is like the general Plug-in  and Agent architecture [similar to OVS], we have in OS is like Plug-in will be in Controller and Agent has to be on the Compute Node.
Right, lbaas plugin runs within quantum-server, lbaas agent may run on network controller or on some compute node (remember that it must run on one host only)

>So, when we are trying for Service Insertion, do we need to have same architecture as Plug-in and Agent above or it should be generic in such a way that independent of underlying Hardware/Products, We should be able to bring up services
I'm not sure I understood your question.
Currently quantum's lbaas plugin supports the only type of loadbalancer and it's not customizible via drivers at this point.

Thanks,
Eugene.

On Thu, Mar 14, 2013 at 6:09 PM, balaji patnala <patnala003 at gmail.com<mailto:patnala003 at gmail.com>> wrote:
Hi Eugene,


>With current lbaas implementation the link that you've provided is not actual as current implementation has adopted different architecture.

Can you point me to the links for current implementation details.


As well the confusion is like the general Plug-in  and Agent architecture [similar to OVS], we have in OS is like Plug-in will be in Controller and Agent has to be on the Compute Node.

So, when we are trying for Service Insertion, do we need to have same architecture as Plug-in and Agent above or it should be generic in such a way that independent of underlying Hardware/Products, We should be able to bring up services.

>Current implementation only supports haproxy-on-the-host solution so it's not suitable for hardware/VM LBs.

So, is this similar to current L3_Agent daemon we have in Quantum for Folsom release?

Thanks,
Balaji.P

On Thu, Mar 14, 2013 at 5:25 PM, Eugene Nikanorov <enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>> wrote:
Hi Balaji,

With current lbaas implementation the link that you've provided is not actual as current implementation has adopted different architecture.

> Can you please through some light on the Agent part of the architecture like where exactly the agent will be running like OpenStack Controller Node or OpenStack Compute Node.?
In grizzly, lbaas agent should run on some node - it could be compute node or network controller node.
The only important is that there MUST be only one instance of lbaas agent running.

Current implementation only supports haproxy-on-the-host solution so it's not suitable for hardware/VM LBs.
Support for such use case is planned in the next release.

Thanks,
Eugene.

On Thu, Mar 14, 2013 at 3:46 PM, balaji patnala <patnala003 at gmail.com<mailto:patnala003 at gmail.com>> wrote:
Hi Ilya,

As described in the document given in the below link:

http://wiki.openstack.org/Quantum/LBaaS/Agent

Agent part will be running on Compute Node or Controller Node ?.

I guess it should be on the Controller Node only. As the driver abstraction layer is for choosing the right driver for the device it has to connect like Driver A to the Device Type A. etc. [This approach is for HW device LB]

If we want to have SW-based-LB like SLB VM, does the above architecture is valid?

Can you please through some light on the Agent part of the architecture like where exactly the agent will be running like OpenStack Controller Node or OpenStack Compute Node.?

Thanks in advance.

Regards,
Balaji.P

On Thu, Feb 7, 2013 at 8:26 PM, Ilya Shakhat <ishakhat at mirantis.com<mailto:ishakhat at mirantis.com>> wrote:
Hi Pattabi,

Code for LBaaS agent and driver API is on review. You may check it from Gerrit topic https://review.openstack.org/#/c/20579. Instructions on how to run the code in DevStack environment are at http://wiki.openstack.org/Quantum/LBaaS/Agent. Driver API is documented at http://wiki.openstack.org/Quantum/LBaaS/DriverAPI

Thanks,
Ilya


2013/2/7 Avishay Balderman <AvishayB at radware.com<mailto:AvishayB at radware.com>>
The basic lbaas driver is not committed yet ? it is under review.

From: Pattabi Ayyasami [mailto:pattabi at Brocade.com<mailto:pattabi at Brocade.com>]
Sent: Thursday, February 07, 2013 3:06 AM
To: openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [Quantum][LBaaS] - LBaaS Extension in Quantum Plugin

Hi,

I am in the process of adding vendor specific plugin implementation for LBaaS as a service. I have my stand alone driver ready and would like to integrate with the framework.
I looked at the latest Git Hub https://github.com/openstack/quantum repository. I do not find any code that allows me to hook my plugin code to the framework.

Really appreciate if someone could provide me any pointers on how I go about doing it.

Regards,
Pattabi

================================================================