[openstack-dev] [Neutron][LBaaS][FWaaS][VPNaaS] Advanced Services (particularly LBaaS) and Neutron
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
Re: [openstack-dev] [Neutron][LBaaS][FWaaS][VPNaaS] Advanced Services (particularly LBaaS) and Neutron
Hi, I have added to https://etherpad.openstack.org/p/AdvancedServices_and_Neutron a note recalling two technical challenges that do not exists when LBaaS runs as a Neutron extension. -Sam. From: Susanne Balle [mailto:sleipnir...@gmail.com] Sent: Wednesday, May 07, 2014 2:45 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Balle, Susanne Subject: [openstack-dev] [Neutron][LBaaS][FWaaS][VPNaaS] Advanced Services (particularly LBaaS) and Neutron 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 backg
Re: [openstack-dev] [Neutron][LBaaS][FWaaS][VPNaaS] Advanced Services (particularly LBaaS) and Neutron
Sam, Perfect. I saw Eugene added something too. Let's get more of the known facts and issues down on the etherpad so we are better prep'ed for the Tues meeting. Susanne On Wed, May 7, 2014 at 9:01 AM, Samuel Bercovici wrote: > Hi, > > I have added to > https://etherpad.openstack.org/p/AdvancedServices_and_Neutron a note > recalling two technical challenges that do not exists when LBaaS runs as a > Neutron extension. > > -Sam. > > > > > > *From:* Susanne Balle [mailto:sleipnir...@gmail.com] > *Sent:* Wednesday, May 07, 2014 2:45 PM > *To:* OpenStack Development Mailing List (not for usage questions) > *Cc:* Balle, Susanne > *Subject:* [openstack-dev] [Neutron][LBaaS][FWaaS][VPNaaS] Advanced > Services (particularly LBaaS) and Neutron > > > > 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
Re: [openstack-dev] [Neutron][LBaaS][FWaaS][VPNaaS] Advanced Services (particularly LBaaS) and Neutron
On Wed, May 7, 2014 at 6:45 AM, Susanne Balle 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. > I've already spoken to Susanne about this multiple times, so I wanted to share my thoughts publicly as well. As the PTL of Neutron, I am not in favor of splitting advanced services out of Neutron. There are many reasons for this, and I'll enumerate some of them here: 1. Splitting services out will actually slow down velocity. 2. Splitting out advanced services would require locking down APIs which are currently internal to Neutron and have not been exposed outside. 3. The advanced services team has worked out a high level plan, along with more detailed blueprints, for the work they plan to execute on in Juno [1] [1] https://review.openstack.org/#/c/92200/ > > > 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 reason services haven't gotten the attention some think they deserved in Icehouse was due to the focus on testing and stability for Neutron during Icehouse. We've made great strides there as a team now, and we're continuing those efforts in Juno. And as I alluded to above, the advanced services team has a working document now, along with sub-documents, for how they plan to move forward on services for Juno (LBaaS, VPNaaS, FWaaS, etc.). As I indicated before, splitting this out would slow velocity amongst other logistical issues. > > > 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. > > Yes, we're working on addressing these as a team. None of the above necessitates a new project being formed. > > 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. > Why? Frankly, any issues you've had on IRC or on the ML would only carry over into a new project. You can't solve logistical problems by adding more layers of bureaucracy. > > > 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
Re: [openstack-dev] [Neutron][LBaaS][FWaaS][VPNaaS] Advanced Services (particularly LBaaS) and Neutron
On May 7, 2014, at 7:45 AM, Susanne Balle mailto:sleipnir...@gmail.com>> wrote: 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 The only reason the advance services team would be out in the cold is that members actively choose not to participate in the broader community. The code, bugs, and reviews are open so contributing more devs resources for the stability fixes would have improved the velocity of stability improvements. Some of the background reasoning for suggesting this is available at: https://etherpad.openstack.org/p/AdvancedServices_and_Neutron I’ve added comment there to provide additional information, but I do not think splitting these out are in the best interest of the community because of the logistical and technical problems it creates. I’d rather see a deeper participation in the broader Neutron community. 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. Look forward to discussing this, mark ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 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>> 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 o
Re: [openstack-dev] [Neutron][LBaaS][FWaaS][VPNaaS] Advanced Services (particularly LBaaS) and Neutron
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 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" 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
