Open Stack

Hi Susanne,

One comment in line.

On Tue, 2014-05-20 at 19:12 -0400, Susanne Balle wrote:
> 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.

I don't think they want Octavia LBaaS to be in stackforge, just the
HA/scalable provider implementation (HaProxy, Nginx, LVS, etc).  So the
API would still be the frontend of the Octavia LBaaS (which would be an
OpenStack project), but the API would call a driver (that still needs to
be created as well) that was written to talk to this HA/scalable
provider implementation.  The actual code for this HA/scalable provider
would exist in stackforge, much like a vendor (radware, netscaler, etc)
would not put their code in the Octavia LBaaS's tree.

Just thought I'd clear that up so we can get other people's thoughts on
this.
> 
>  
> 
> 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