Open Stack

For the record, I agree with you, Roman, on all your points below, and I
hope that LBaaS will be added to Quantum in the Grizzly timeframe (as
experimental) and stabilize within Quantum afterwards.

I'm not going to get into the whole Java vs. Python thing. That ship has
sailed, IMHO. It's really got to be Python to go into core and certainly
got to be Python to go into Quantum, which is where I believe the code
belongs...

Best,
-jay

On 08/21/2012 04:50 PM, Roman Alekseenkov wrote:
> 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)
>  2. 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
>  2. 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
>  3. 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
> 
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>