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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
