<div dir="ltr"><p class="MsoNormal"><br></p><p class="MsoNormal">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.</p><p class="MsoNormal"><br></p><p class="MsoNormal">Feel free to chime in if I misrepresented anything or if you disagree :-)</p><p class="MsoNormal"> </p><p class="MsoNormal">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. </p><p class="MsoNormal"> </p><p class="MsoNormal"><b>Goal:</b></p><p class="MsoNormal">We all want to create a best in class “operator scale” Octavia
LBaaS service to our customers.</p><p class="MsoNormal">Following requirements need to be considered (these are
already listed in some of the etherpads we have worked on)</p><p class="" style><span style="font-family:Symbol">·<span style="font-size:7pt;font-family:'Times New Roman'">
</span></span>Provides scalability, failover, config
management, and provisioning.</p><p class="" style><span style="font-family:Symbol">·<span style="font-size:7pt;font-family:'Times New Roman'">
</span></span>Architecture need to be pluggable so we can
offer support for HAProxy, Nginx, LVS, etc.</p><p class="MsoNormal"> </p><p class="MsoNormal"><b>Some disagreements exist
around the scope of the new project: </b></p><p class="MsoNormal"> </p><p class="MsoNormal">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. <a href="http://www.openstack.org/software/">http://www.openstack.org/software/</a></p><p class="" style="margin-left:0.25in"><span style="font-family:Symbol">·<span style="font-size:7pt;font-family:'Times New Roman'">
</span></span>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.</p><p class="" style="margin-left:0.25in"><span style="font-family:Symbol">·<span style="font-size:7pt;font-family:'Times New Roman'">
</span></span>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.</p><p class="" style="margin-left:0.75in"><span style="font-family:'Courier New'">o<span style="font-size:7pt;font-family:'Times New Roman'"> </span></span>We
would start out as a driver to Neutron.</p><p class="" style="margin-left:0.75in"><span style="font-family:'Courier New'">o<span style="font-size:7pt;font-family:'Times New Roman'"> </span></span>This
project would deprecate Neutron LBaaS long term since part of the Neutron LBaaS
would move over to the Octavia LBaaS project.</p><p class="" style="margin-left:0.75in"><span style="font-family:'Courier New'">o<span style="font-size:7pt;font-family:'Times New Roman'"> </span></span>This
project would continue to support both vendor drivers and new software drivers
e.g. ha-proxy, etc.</p><p class="" style="margin-left:0.25in"><span style="font-family:Symbol">·<span style="font-size:7pt;font-family:'Times New Roman'">
</span></span>Dougwig created the following diagram which
gives a good overview of my thinking: <a href="http://imgur.com/cJ63ts3">http://imgur.com/cJ63ts3</a>
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</p><p class="MsoNormal"> </p><p class="MsoNormal">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. </p><p class="" style="margin-left:0.25in"><span style="font-family:Symbol">·<span style="font-size:7pt;font-family:'Times New Roman'">
</span></span>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.</p><p class="MsoNormal"> </p><p class="MsoNormal">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.</p><p class="MsoNormal"> </p><p class="MsoNormal">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.</p><p class="MsoNormal"> </p><p class="MsoNormal"><b>How do we think we
can do it?</b></p><p class="MsoNormal"> </p><p class="MsoNormal">We have some agreement around the following approach:</p><p class="MsoNormal"> </p><p class="" style="margin-left:0.25in"><span style="font-family:Symbol">·<span style="font-size:7pt;font-family:'Times New Roman'">
</span></span>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.</p><p class="" style="margin-left:0.75in"><span style="font-family:'Courier New'">o<span style="font-size:7pt;font-family:'Times New Roman'"> </span></span>We
would use Gerrit for blueprints so we have documented reviews and comments
archived somewhere.</p><p class="" style="margin-left:0.75in"><span style="font-family:'Courier New'">o<span style="font-size:7pt;font-family:'Times New Roman'"> </span></span>Contribute
patches regularly into the Neutron LBaaS tree:</p><p class="" style="margin-left:1.25in"><span style="font-family:Wingdings">§<span style="font-size:7pt;font-family:'Times New Roman'"> </span></span>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.</p><p class="MsoNormal"> </p><p class="MsoNormal">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.</p><p class="MsoNormal">Carefully planning the various transitions.</p><p class="MsoNormal"> </p><p class="MsoNormal">
</p><p class="MsoNormal">Regards Susanne</p></div>