Hi,

The pods are actually in level 2.

Thanks,
German

From: Susanne Balle [mailto:sleipnir...@gmail.com]
Sent: Monday, May 12, 2014 11:45 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Monty Taylor; Jay Pipes; Nachi Ueno; Sumit Naiksatam; Kyle Mestery; 
mmccl...@yahoo-inc.com; Barclay, Alex (HPCS Seattle); Adam Harwell; Eugene 
Nikanorov; jorge.miramon...@rackspace.com; Stephen Balukoff; Eichberger, 
German; Cuddy, Tim
Subject: Re: [openstack-dev] [Neutron][LBaaS][FWaaS][VPNaaS] Advanced Services 
(particularly LBaaS) and Neutron

I apologize if you received this email already ....

Reminder that we plan to meet tomorrow

Tuesday May 13 at 2pm at the Neutron pod on level 3.

Susanne

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.

On Mon, May 12, 2014 at 12:40 PM, Balle, Susanne 
<susanne.ba...@hp.com<mailto:susanne.ba...@hp.com>> wrote:
Reminder that we plan to meet tomorrow

Tuesday May 13 at 2pm at the Neutron pod on level 3.

Susanne

Sent from my iPhone

On May 7, 2014, at 7:45 AM, "Susanne Balle" 
<sleipnir...@gmail.com<mailto:sleipnir...@gmail.com><mailto:sleipnir...@gmail.com<mailto:sleipnir...@gmail.com>>>
 wrote:

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

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to