Open Stack

Thanks Eugene for the update. I am looking forward to the Open Stack Summit Design Discussions.

Regards,
Pattabi


From: Eugene Nikanorov [mailto:enikanorov at mirantis.com]
Sent: Thursday, March 28, 2013 11:10 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Quantum][LBaaS]- - LBaaS Extension in Quantum Plugin

Hi, Pattabi,

Yes, it's better to wait for the summit prior to implementing device drivers.
It's seems that there will be two major approaches competing, which probably would require different versions of lbaas plugin.

Currently regular lbaas meetings are not held.
I think it will change after the summit as the direction for the further service development will be set.

> 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.
Current "reference implementation" is focused on HAProxy and does not directly support pluggable device drivers.
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.

Thanks,
Eugene.

On Fri, Mar 29, 2013 at 7:24 AM, Monty Taylor <mordred at inaugust.com<mailto:mordred at inaugust.com>> wrote:
On 03/28/2013 11:14 PM, Pattabi Ayyasami wrote:
>
> 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.
Awesome! Happy to know that you've done that.

> 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?
Our system automatically abandons patches with negative reviews after a
week so that we don't keep a lot of cruft around. In this case though,
Dan just put a -2 on the review to prevent it from accidentally getting
merged before we open up development for havana again. As soon as havana
is open, we can restore that patch and work on getting it applied - so
no need to worry!

> 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><mailto: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><mailto: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><mailto: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><mailto: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><mailto: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><mailto: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><mailto: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><mailto: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><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><mailto: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
>
> ================================================================
>
>
> _______________________________________________ OpenStack-dev mailing
> list OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130401/5315e1fd/attachment.html>