Open Stack

Hi folks,

Sounds like you all had an eventful meeting today.  My opinion here is
that the goal of these meetings should be to prepare for summit
discussions by understanding each others existing LBaaS systems,
recording common use cases and requirements, and to identifying key
questions.  It sounds like the meeting today veered more into
implementation and project management details.  Remember that any
meetings you do have are merely "summit prep", not final decisions by
the community, and that I'd encourage you all .

My basic feeling here is that a path to delivering LBaaS as part of a
"core" OpenStack project is what we should be focused on.  Quantum
will be moving into L4-L7 services including load-balancing during
Grizzly, which will achieve the goal of a python-based and fully core
solution (I see no other route for LBaaS to be in a core project in
Grizzly, as any new project would need to go through incubation first
before becoming core).  With this in mind, we'll be devoting several
Quantum sessions at the design summit to this topic. We'd love if
everyone in the OpenStack community, particularly from the Atlas team,
joins this effort, so we can benefit from more team members and
experience.

I'm adding Thierry to the thread in case he feels a desire to comment
(no need, as most of us are pretty focused on delivering Folsom at
this point).

Dan

On Tue, Aug 21, 2012 at 1:50 PM, Roman Alekseenkov
<ralekseenkov at mirantis.com> 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:
>
> 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)
>
> 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:
>
> 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
>
> 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
> 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> 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>
> 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
>
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~