<div dir="ltr"><p class="MsoNormal">Hi Advanced Services/LBaaS Stackers, </p>

<p class="MsoNormal"> </p>

<p class="MsoNormal">We are setting up a meeting to discuss if it makes sense to
separate the advanced services (LBaaS, FW, VPNaaS) from Neutron into separate
projects. We want a healthy discussion around 
the pros and cons of separating the advanced services from Neutron and
its short or long term feasibility.</p>

<p class="MsoNormal"> </p>

<p class="MsoNormal">The meeting is planned for: </p>

<p class="MsoNormal"><b>                Tuesday May 13th at 2pm in the
Neutron pod.</b></p>

<p class="MsoNormal"> </p>

<p class="MsoNormal"><span style="background-repeat:initial initial">There will be a designated pod for
each of the official programs at:</span> <a href="https://wiki.openstack.org/wiki/Programs" target="_blank"><span style="background-repeat:initial initial">https://wiki.openstack.org/wiki/Programs</span></a></p>

<p class="MsoNormal"><span style="background-repeat:initial initial">Some programs share a pod. There
will be a map at the center of the</span> space, as well as signage up to help
find the relevant pod.</p>

<p class="MsoNormal"> </p>

<p class="MsoNormal"><span style="color:black">Based on discussions with Rackspace, Mirantis, and others it is
clear that the advanced services (i.e. LBaaS) in Neutron are not getting the
attention and the support to move forward and create a first in class load-balancer
service; from a service provider or operator's perspective. We currently have a
lot of momentum and energy behind the LBaaS effort but are being told that the
focus for Neutron is bug fixing given the instability in Neutron itself. While
the latter is totally understandable, as a high priority for Neutron it
leaves the advanced services out in the cold with no way to make progress in
developing features that are needed to support the many companies that rely on
LBaaS for large scale deployments.</span></p>

<p class="MsoNormal"><span style="color:black"> </span></p>

<p class="MsoNormal"><span style="color:black">The current Neutron LB API and feature set meet minimum
requirements for small-medium private cloud deployments, but does not meet the
needs of larger, provider (or operator) deployments that include hundreds if
not thousands of load balancers and multiple domain users (discrete customer
organizations). The OpenStack LBaaS community looked at requirements and noted
that the following operator-focused requirements are currently missing:</span></p>

<p class="MsoNormal"><span style="color:black"> </span></p>

<p class="MsoNormal" style="margin-left:0.25in"><span style="font-size:10pt;font-family:Symbol;color:black">·<span style="font-size:7pt;font-family:'Times New Roman'">        
</span></span><span style="color:black">Scalability</span></p>

<p class="MsoNormal" style="margin-left:0.25in"><span style="font-size:10pt;font-family:Symbol;color:black">·<span style="font-size:7pt;font-family:'Times New Roman'">        
</span></span><span style="color:black">SSL
Certificate management – for an operator-based service, SSL certificate
management is a much more important function that is currently not addressed in
the current API or blueprint</span></p>

<p class="MsoNormal" style="margin-left:0.25in"><span style="font-size:10pt;font-family:Symbol;color:black">·<span style="font-size:7pt;font-family:'Times New Roman'">        
</span></span><span style="color:black">Metrics
Collection – a very limited set of metrics are currently provided by the
current API.  </span></p>

<p class="MsoNormal" style="margin-left:0.25in"><span style="font-size:10pt;font-family:Symbol;color:black">·<span style="font-size:7pt;font-family:'Times New Roman'">        
</span></span><span style="color:black">Separate
admin API for NOC and support operations</span></p>

<p class="MsoNormal" style="margin-left:0.25in"><span style="font-size:10pt;font-family:Symbol;color:black">·<span style="font-size:7pt;font-family:'Times New Roman'">        
</span></span><span style="color:black">Minimal
downtime when migrating to newer versions</span></p>

<p class="MsoNormal" style="margin-left:0.25in"><span style="font-size:10pt;font-family:Symbol;color:black">·<span style="font-size:7pt;font-family:'Times New Roman'">        
</span></span><span style="color:black">Ability
to migrate load balancers (SW to HW, etc.)</span></p>

<p class="MsoNormal" style="margin-left:0.25in"><span style="font-size:10pt;font-family:Symbol;color:black">·<span style="font-size:7pt;font-family:'Times New Roman'">        
</span></span><span style="color:black">Resiliency
functions like HA and failover</span></p>

<p class="MsoNormal" style="margin-left:0.25in"><span style="font-size:10pt;font-family:Symbol;color:black">·<span style="font-size:7pt;font-family:'Times New Roman'">        
</span></span><span style="color:black">Operator-based
load balancer health checks</span></p>

<p class="MsoNormal" style="margin-left:0.25in"><span style="font-size:10pt;font-family:Symbol;color:black">·<span style="font-size:7pt;font-family:'Times New Roman'">        
</span></span><span style="color:black">Support
multiple, simultaneous drivers.</span></p>

<p class="MsoNormal"> </p>

<p class="MsoNormal">We have had great discussions on the LBaaS mailing list and on IRC
about all the things we want to do, the new APIs, the User use cases,
requirements and priorities, the operator requirements for LBaaS, etc. and I am
at this point wondering if Neutron LBaaS as a sub-project of Neutron can fulfill
our requirements. </p>

<p class="MsoNormal"> </p>

<p class="MsoNormal">I would like this group to discuss the pros and cons of separating
the advanced services, including LB, VPN, and FW, out of Neutron and allow
for each of the three currently existing advanced services to become
stand-alone projects or one standalone project. </p>

<p class="MsoNormal">  </p>

<p class="MsoNormal">This should be done under the following assumptions:</p>

<p class="" style><span style="font-family:Symbol">·<span style="font-size:7pt;font-family:'Times New Roman'">        
</span></span>Keep backwards compatibility with the current
Neutron LBaaS plugin/driver API (to some point) so that existing
drivers/plug-ins continues to work for people who have already invested in
Neutron LBaaS</p>

<p class="" style><span style="font-family:Symbol">·<span style="font-size:7pt;font-family:'Times New Roman'">        
</span></span>Migration strategy. </p>

<p class="MsoNormal"> </p>

<p class="MsoNormal">We have a precedence in OpenStack of splitting up services that
are becoming too big or where sub-services deserve to become an entity of its
own e.g. baremetal Nova and Ironic, Nova-network and Neutron, nova-scheduler is
being worked into the Gantt project, etc.</p>

<p class="MsoNormal"> </p>

<p class="MsoNormal">At a high-level I see the following steps/blueprints needing to be
carried out:</p>

<p class="" style><span style="font-family:Symbol">·<span style="font-size:7pt;font-family:'Times New Roman'">        
</span></span>Identify and create a library similar in
concept to OpenStack core that contains the common components pieces needed by
the advanced services in order to minimize code duplication between the advanced
services and Neutron. This library should be consumable by external projects
and will allow for cleaner code reuse by not only the three existing advanced
services but by new services as well.</p>

<p class="" style><span style="font-family:Symbol">·<span style="font-size:7pt;font-family:'Times New Roman'">        
</span></span>Start a new repo for the standalone
LBaaS </p>

<p class="" style="margin-left:1in"><span style="font-family:'Courier New'">o<span style="font-size:7pt;font-family:'Times New Roman'">   </span></span><a href="http://git.openstack.org/cgit/openstack-dev/cookiecutter/tree/">http://git.openstack.org/cgit/openstack-dev/cookiecutter/tree/</a></p>


<p class="" style><span style="font-family:Symbol">·<span style="font-size:7pt;font-family:'Times New Roman'">        
</span></span>Write a patch to bridge Neutron LBaaS with the
standalone LBaaS for backwards compatibility. Longer term we can deprecate
Neutron LBaaS  which will be possible once the new LBaaS service is a
graduated OpenStack service. </p>

<p class="MsoNormal"> </p>

<p class="MsoNormal">Some of the background reasoning for suggesting this is available
at:</p>

<p class="MsoNormal"><a href="https://etherpad.openstack.org/p/AdvancedServices_and_Neutron">https://etherpad.openstack.org/p/AdvancedServices_and_Neutron</a></p>

<p class="MsoNormal"> </p>

<p class="MsoNormal">Hope to see you there to discuss how we best make sure that the
advanced services can<span style="color:black">
support the many companies that rely on LBaaS or other advanced services for
large scale deployment. </span></p>

<p class="MsoNormal"><span style="color:black"> </span></p>

<p class="MsoNormal"><span style="color:black">Regards
Susanne</span></p></div>