Open Stack

Balaji

The plan is to work on the next version of the LBaaS APIs in parallel to
maintaining the current version of the APIs and at some point when
everything is ready have a plan to deprecate the old APIs.

Susanne


On Wed, May 21, 2014 at 7:31 AM, Balaji.P at freescale.com <
Balaji.P at freescale.com> wrote:

>  Hi Susanne,
>
>
>
> Was there any  discussion happened on LBaaS Neutron API [which are
> available now] will be modified while migrating to Octavia.?
>
>
>
> Just want to understand the impact on the current LBaaS implementation
> using folks and migrating to Octavia.
>
>
>
> Regards,
>
> Balaji.P
>
>
>
> *From:* Susanne Balle [mailto:sleipnir012 at gmail.com]
> *Sent:* Wednesday, May 21, 2014 4:36 AM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Cc:* Cuddy, Tim; Balle, Susanne; vbhamidipati at paypal.com
>
> *Subject:* [openstack-dev] [Neutron][LBaaS] Neutron LBaaS "operator
> scale" service --- Next steps and goals.
>
>
>
>
>
> We have had some discussions around how to move forward with the LBaaS
> service in OpenStack.  I am trying to summarize the key points below.
>
>
>
> Feel free to chime in if I misrepresented anything or if you disagree :-)
>
>
>
> For simplicity in the rest of the email and so I can differentiate between
> all the LBaaS’s e.g. Neutron LBaaS, etc… I will name the new OpenStack
> LBaaS project (that we discussed at the summit): Octavia in the rest of
> this email. Note that this doesn’t mean we have agree on this name.
>
>
>
> *Goal:*
>
> We all want to create a best in class “operator scale” Octavia LBaaS
> service to our customers.
>
> Following requirements need to be considered (these are already listed in
> some of the etherpads we have worked on)
>
> ·         Provides scalability, failover, config management, and
> provisioning.
>
> ·         Architecture need to be pluggable so we can offer support for
> HAProxy, Nginx, LVS, etc.
>
>
>
> *Some disagreements exist around the scope of the new project: *
>
>
>
> Some of the participating companies including HP are interested in a best
> in class standalone Octavia load-balancer service that is part of OpenStack
> and with the “label” OpenStack. http://www.openstack.org/software/
>
> ·         The Octavia LBaaS project needs to work well with OpenStack or
> this effort is not worth doing. HP believes that this should be the primary
> focus.
>
> ·         In this case the end goal would be to have a clean interface
> between Neutron and the standalone Octavia LBaaS project and have the
> Octavia LBaaS project become an incubated and eventual graduated OpenStack
> project.
>
> o   We would start out as a driver to Neutron.
>
> o   This project would deprecate Neutron LBaaS long term since part of
> the Neutron LBaaS would move over to the Octavia LBaaS project.
>
> o   This project would continue to support both vendor drivers and new
> software drivers e.g. ha-proxy, etc.
>
> ·         Dougwig created the following diagram which gives a good
> overview of my thinking: http://imgur.com/cJ63ts3 where Octavia is
> represented by “New Driver Interface” and down. The whole picture shows how
> we could move from the old to the new driver interface
>
>
>
> Other participating companies want to create a best in class standalone
> load-balancer service outside of OpenStack and only create a driver to
> integrate with Openstack Neutron LBaaS.
>
> ·         The Octavia LBaaS driver would be part of Neutron LBaaS tree
> whereas the Octavia LBaaS implementation would reside outside OpenStack
> e.g. Stackforge or github, etc.
>
>
>
> The main issue/confusion is that some of us (HP LBaaS team) do not think
> of projects in StackForge as OpenStack branded. HP developed  Libra LBaaS
> which is open sourced in StackForge and when we tried to get it into
> OpenStack we met resistance.
>
>
>
> One person suggested the idea of designing the Octavia LBaaS service
> totally independent of Neutron or any other service that calls. This might
> makes sense for a general LBaaS service but given that we are in the
> context of OpenStack this to me just makes the whole testing and developing
> a nightmare to maintain and not necessary. Again IMHO we are developing and
> delivering Octavia in the context of OpenStack so the Octavia LBaaS  should
> just be super good at dealing with the OpenStack env. The architecture can
> still be designed to be pluggable but my experiences tell me that we will
> have to make decision and trade-offs and at that point we need to remember
> that we are doing this in the context of OpenStack and not in the general
> context.
>
>
>
> *How do we think we can do it?*
>
>
>
> We have some agreement around the following approach:
>
>
>
> ·         To start developing the driver/Octavia implementation in
> StackForge which should allow us to increase the velocity of our
> development using the OpenStack CI/CD tooling (incl. jenkins) to ensure
> that we test any change. This will allow us to ensure that changes to
> Neutron do not break our driver/implementation as well as the other way
> around.
>
> o   We would use Gerrit for blueprints so we have documented reviews and
> comments archived somewhere.
>
> o   Contribute patches regularly into the Neutron LBaaS tree:
>
> §  Kyle has volunteered himself and one more core team members to review
> and help move a larger patch into Neutron tree when needed. It was also
> suggested that we could do milestones of smaller patches to be merged into
> Neutron LbaaS. The latter approach was preferred by most participants.
>
>
>
> The main goal behind this approach is to make sure we increase velocity
> while still maintaining a good code/design quality. The OpenStack tooling
> has shown to work for large distributed virtual teams so let's take
> advantage of it.
>
> Carefully planning the various transitions.
>
>
>
> Regards Susanne
>
> _______________________________________________
> OpenStack-dev mailing list
> 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/20140521/0d4f487b/attachment.html>