[openstack-dev] LBaaS & Quantum - Design Summit Preparation

Samuel Bercovici SamuelB at Radware.com
Wed Aug 22 21:13:27 UTC 2012


Hi,

I think that it should be our primary interest to have LBaaS easily available and nicely integrated with OpenStack and Quantum .

The way how this is implemented (Java / Python) should be on a much lesser importance since if for argument sake we will create the "best LBaaS the world has ever seen" but it is not part of the core Open Stack solution, the market exposure and the ability to actually get customers to adopt this will be reduces.
Atlas-LB which I think is a good solution and we (Radware) has invested some effort in it, is available for quite a long time, but as far as I am aware the only adoption it has so far is by Rackspace who have originally contributed it.
It is of interest to understand why several of the other public clouds that are using OpenStack did not decide to also use Atlas-LB (yet?)
I suspect, that this might be due to the additional complexity involved in adding and using a project which is not part of the core OpenStack solution.

Based on what was said here by Dan and the quotes Roman has pointed to (we can also discuss this further on the summit), if Python is the only way to achieve this, that by all means this is how we need to proceed.
On the other hand, if based on our analysis, we will find that there is a substantial difference between a new Python based solution or one of the other Java based ones (Atlas-LB or EBay). it might be worth to discuss and exception from the PPB.

To conduct a such a discussion and drive to a decision we should have listed the appropriate requirements and blue prints that we agree are needed for LBaaS.
The end result would serve us anyway to stir the features and directions of this solution.

Should we host such a requirement list /blue print list on the wiki page or is there another place to start?


Regards,
                -Sam.



From: Roman Alekseenkov [mailto:ralekseenkov at mirantis.com]
Sent: Tuesday, August 21, 2012 11:50 PM
To: Palanisamy, Anand; John Gruber; Eugene Kirpichev; Alex Gosse; Raja Srinivasan; Kobi Samoray; Youcef Laribi; Martin, JC; Brodskiy, Yuriy; Busby, Brent; smaskalik at vmware.com; somik at nicira.com; dan at nicira.com; Daniels, Alsontra; Colorado, Kim; Mcwilliams, Brad; Jain, Vivek; Punati, Ravi; Instenes, Shawn; Narancic, Chris; 'Somik Behera'; Avishay Balderman; Samuel Bercovici; 'Jorge Miramontes'; Malkowski Jr, Marvin; Cotton, Dave; Gandhi, Kunal; openstack-dev at lists.openstack.org
Subject: Re: LBaaS & Quantum - Design Summit Preparation

As OpenStack project types were discussed in the end of today's LBaaS meeting, I would like to share the relevant links http://wiki.openstack.org/Projects and http://wiki.openstack.org/ProjectTypes.

Now, straight to the point. I made an attempt here to summarize all opinions in order to make a constructive dialog regarding Java vs. Python, and place of LBaaS in OpenStack. All of these answers are from PPB members:

  1.  Language:

     *   Thierry (PPB): core projects should be in Python, exceptions are up to PPB (https://lists.launchpad.net/openstack/msg15092.html)
     *   Dan (PPB): core projects should be in Python, exceptions are up to PPB (https://lists.launchpad.net/openstack/msg15128.html)

  1.  Where LBaaS should land:

     *   Dan (PPB): L4-L7 services are within scope of Quantum. LBaaS makes sense as a sub-component of Quantum, but ultimately the decision is up to PPB (https://lists.launchpad.net/openstack/msg15128.html)
     *   Jesse (PPB): not clear whether LBaaS belongs to IaaS or PaaS, and whether it is essential to be included into OpenStack core (https://lists.launchpad.net/openstack/msg07306.html)
Now I wanted to share my own personal opinion. Not on the language and specific implementation (these discussions were not very productive lately), but on where LBaaS should land. So far we only have Dan's definitive opinion, so I think mine will be the second:

  1.  LBaaS is a very important service/feature

     *   there is such a large audience being present on regular LBaaS meetings
     *   we have already discussed a number of different LB use cases
     *   vendors are interested in moving it forward (F5, Citrix, Radware, Cisco, HP, etc)
     *   ultimately, application delivery is the key. LB plays an important role here
     *   look at all public clouds out there

  1.  I completely agree with the vision that OpenStack is not IaaS + PaaS. And LB devices nicely fall into IaaS especially when we are talking about hardware load balancers. See http://en.wikipedia.org/wiki/Cloud_computing & http://en.wikipedia.org/wiki/File:Cloud_computing_layers.png
  2.  If a decision is made to proceed with non-core route for LBaaS, that would mean

     *   no load balancing functionality out-of-the-box (imagine Amazon without ELB)
     *   people will have to download, set up and plug in an external component for LB, likely Java-based
     *   this component will likely be on a separate release schedule, independent of OpenStack
     *   people will less likely want to use it & there will be a barrier for adoption (that's what we already seeing with 2 of our customers)
     *   LBaaS being outside of core adds another layer of complexity for people who want to upgrade their OpenStack installation and/or LBaaS. In ideal world I would imagine OpenStack having an "appstore" for add-ons (LBaaS, billing, monitoring, etc) and everything works flawlessly including upgrades, but in the current form of "ecosystem around core" I can't quite imagine LBaaS being an important outside component
Therefore, I think we should try to get LBaaS feature set into core (disclaimer -- this is, again, my personal opinion). This means either having a Python implementation, or Java-based implementation + exception from PPB. Keeping Atlas as a "Related" Java project does not seem to be the best option as it will not actually change much in terms of current adoption & traction, and also for the reasons which I described above.

P.S.
"Related projects are unofficial projects with no rights to use OpenStack brand and assets or project resources. Related projects are made of up projects that have chosen to associate themselves with OpenStack. These projects are not officially tied to OpenStack or any OpenStack processes or resources, but may make use of OpenStack or add functionality on top of OpenStack projects. The "related project" designation is meant to provide an aggregation method for the community to expose useful projects and products in the OpenStack ecosystem that are not directly part of the core or incubated projects."

Thanks,
Roman


On 8/20/12 12:26 PM, "Palanisamy, Anand" <apalanisamy at paypal.com<mailto:apalanisamy at paypal.com>> wrote:

The wiki is updated for eBay LBaaS project. http://wiki.openstack.org/Quantum/LBaaS

Thanks
Anand

From: apalanisamy at paypal.com<mailto:apalanisamy at paypal.com><mailto:apalanisamy at paypal.com>
When: 9:00 AM - 10:00 AM August 21, 2012
Subject: LBaaS & Quantum - Design Summit Preparation
Location: 11 /11.2.057 Ahoy (18)


Dan,

Pls. share the wiki link and I will add the eBay Design Docs before the next week meeting.

-----
Agenda:

  *   eBay LBaaS Demo
  *   Comparison with Mirantis LBaaS, Atlas-LB
  *   Take Aways for Design Summit

Location:
eBay/PayPal Inc.
2211 N 1st st
San Jose, CA 95131 USA

https://myroom-na.adobeconnect.com/anandpalanisamy/

(855) 227-1767(USA) - 08003765931(UK)  Conf. Code 7152259

0008006103229 (India - Toll Free)
81080024322044(Moscow)  4992701688(Moscow)

https://www.intercallonline.com/portlets/scheduling/viewNumbers/listNumbersByCode.do?confCode=7152259&name=&email=&selectedProduct=joinMeeting


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120822/a228a318/attachment-0001.html>


More information about the OpenStack-dev mailing list