Open Stack

Hi All,

Here are my own opinions...


The Stingray Business Unit within Riverbed have already been investigating
integration with Atlas and Quantum.  Certainly, one of the main reasons
why we haven't taken a much more vocal/active role in Atlas' development
is because the path to market with Atlas seems relatively long.  I
completely agree with [what I interpret to be] Dan and Roman's opinion in
that the fastest way to market for *all* vendors is to get LB integration
(whether it's strictly "LBaaS" or not) into a "core" OpenStack project.

I appreciate that a great deal of time and effort has gone into Atlas over
the last year, most notably from Rackspace and Citrix.  However, I also
recognize that Quantum is already a core component, and I can't help but
feel that we would get an awful lot "for free" if we focused our
collective knowledge about the various APIs and object models into the
upcoming design.

The LBaaS demo screencast that was recorded by Mirantis is intriguing
enough that I have kicked off [literally yesterday] an investigative
project to see if we can produce a fuctional, non-production prototype
driver for Stingray (formerly known as Zeus Traffic Manager) in the
Mirantis Python implementation.

Kind regards,
-- 
Alex

On 8/21/12 10:31 PM, "Dan Wendlandt" <dan at nicira.com> wrote:

>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/listNumbe
>>rsByCode.do?confCode=7152259&name=&email=&selectedProduct=joinMeeting
>>
>>
>
>
>
>-- 
>~~~~~~~~~~~~~~~~~~~~~~~~~~~
>Dan Wendlandt
>Nicira, Inc: www.nicira.com
>twitter: danwendlandt
>~~~~~~~~~~~~~~~~~~~~~~~~~~~