Open Stack

Hi Advanced Services/LBaaS Stackers,



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.



The meeting is planned for:

*                Tuesday May 13th at 2pm in the Neutron pod.*



There will be a designated pod for each of the official programs at:
https://wiki.openstack.org/wiki/Programs

Some programs share a pod. There will be a map at the center of the space,
as well as signage up to help find the relevant pod.



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.



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:



·         Scalability

·         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

·         Metrics Collection – a very limited set of metrics are currently
provided by the current API.

·         Separate admin API for NOC and support operations

·         Minimal downtime when migrating to newer versions

·         Ability to migrate load balancers (SW to HW, etc.)

·         Resiliency functions like HA and failover

·         Operator-based load balancer health checks

·         Support multiple, simultaneous drivers.



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.



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.



This should be done under the following assumptions:

·         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

·         Migration strategy.



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.



At a high-level I see the following steps/blueprints needing to be carried
out:

·         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.

·         Start a new repo for the standalone LBaaS

o   http://git.openstack.org/cgit/openstack-dev/cookiecutter/tree/

·         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.



Some of the background reasoning for suggesting this is available at:

https://etherpad.openstack.org/p/AdvancedServices_and_Neutron



Hope to see you there to discuss how we best make sure that the advanced
services can support the many companies that rely on LBaaS or other
advanced services for large scale deployment.



Regards Susanne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140507/698616b8/attachment.html>