<div dir="ltr">Balaji<div><br></div><div>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.</div>
<div><br></div><div>Susanne</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 21, 2014 at 7:31 AM, <a href="mailto:Balaji.P@freescale.com">Balaji.P@freescale.com</a> <span dir="ltr"><<a href="mailto:Balaji.P@freescale.com" target="_blank">Balaji.P@freescale.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi Susanne,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Was there any discussion happened on LBaaS Neutron API [which are available now] will be modified while migrating to Octavia.?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Just want to understand the impact on the current LBaaS implementation using folks and migrating to Octavia.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Regards,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Balaji.P<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Susanne Balle [mailto:<a href="mailto:sleipnir012@gmail.com" target="_blank">sleipnir012@gmail.com</a>]
<br>
<b>Sent:</b> Wednesday, May 21, 2014 4:36 AM</span></p><div class=""><br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
</div><b>Cc:</b> Cuddy, Tim; Balle, Susanne; <a href="mailto:vbhamidipati@paypal.com" target="_blank">vbhamidipati@paypal.com</a><div class=""><br>
<b>Subject:</b> [openstack-dev] [Neutron][LBaaS] Neutron LBaaS "operator scale" service --- Next steps and goals.<u></u><u></u></div><p></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></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.<u></u><u></u></p><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Feel free to chime in if I misrepresented anything or if you disagree :-)<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></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.
<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><b>Goal:</b><u></u><u></u></p>
<p class="MsoNormal">We all want to create a best in class “operator scale” Octavia LBaaS service to our customers.<u></u><u></u></p>
<p class="MsoNormal">Following requirements need to be considered (these are already listed in some of the etherpads we have worked on)<u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:Symbol">·</span><span style="font-size:7.0pt">
</span>Provides scalability, failover, config management, and provisioning.<u></u><u></u></p>
<p class="MsoNormal"><span style="font-family:Symbol">·</span><span style="font-size:7.0pt">
</span>Architecture need to be pluggable so we can offer support for HAProxy, Nginx, LVS, etc.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><b>Some disagreements exist around the scope of the new project:
</b><u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></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/" target="_blank">http://www.openstack.org/software/</a><u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.25in">
<span style="font-family:Symbol">·</span><span style="font-size:7.0pt"> </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.<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.25in">
<span style="font-family:Symbol">·</span><span style="font-size:7.0pt"> </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.<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.75in">
<span style="font-family:"Courier New"">o</span><span style="font-size:7.0pt"> </span>
We would start out as a driver to Neutron.<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.75in">
<span style="font-family:"Courier New"">o</span><span style="font-size:7.0pt"> </span>
This project would deprecate Neutron LBaaS long term since part of the Neutron LBaaS would move over to the Octavia LBaaS project.<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.75in">
<span style="font-family:"Courier New"">o</span><span style="font-size:7.0pt"> </span>
This project would continue to support both vendor drivers and new software drivers e.g. ha-proxy, etc.<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.25in">
<span style="font-family:Symbol">·</span><span style="font-size:7.0pt"> </span>
Dougwig created the following diagram which gives a good overview of my thinking:
<a href="http://imgur.com/cJ63ts3" target="_blank">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<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></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.
<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.25in">
<span style="font-family:Symbol">·</span><span style="font-size:7.0pt"> </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.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></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.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></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.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal"><b>How do we think we can do it?</b><u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">We have some agreement around the following approach:<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.25in">
<span style="font-family:Symbol">·</span><span style="font-size:7.0pt"> </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.<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.75in">
<span style="font-family:"Courier New"">o</span><span style="font-size:7.0pt"> </span>
We would use Gerrit for blueprints so we have documented reviews and comments archived somewhere.<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:.75in">
<span style="font-family:"Courier New"">o</span><span style="font-size:7.0pt"> </span>
Contribute patches regularly into the Neutron LBaaS tree:<u></u><u></u></p>
<p class="MsoNormal" style="margin-left:1.25in">
<span style="font-family:Wingdings">§</span><span style="font-size:7.0pt"> </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.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></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.<u></u><u></u></p>
<p class="MsoNormal">Carefully planning the various transitions.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Regards Susanne<u></u><u></u></p>
</div></div></div>
</div>
</div>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>