Remove Neutron LBaaS

Neutron-LBaaS has now been retired and there will be no Train
release[1]. This patch removes neutron-lbaas references from


Closes-Bug: #1833125
Change-Id: I0fe3fbaf4adf7fb104632fd94cd093e701e12289
Michael Johnson 3 years ago committed by Slawek Kaplonski
parent 090ede21b0
commit d1d0a04c37
  1. 76
  2. 57
  3. 501
  4. 2
  5. 1
  6. 2
  7. 7
  8. 2
  9. 2
  10. 4
  11. 2
  12. 2
  13. 9
  14. 4
  15. 6
  16. 6
  17. 2
  18. 2
  19. 2
  20. 25
  21. 1
  22. 2
  23. 8
  24. 2
  25. 2
  26. 3
  27. 2
  28. 29
  29. 50
  30. 38
  31. 8
  32. 54
  33. 5
  34. 6

@ -5,8 +5,8 @@ Configure neutron agents
Plug-ins typically have requirements for particular software that must
be run on each node that handles data packets. This includes any node
that runs nova-compute and nodes that run dedicated OpenStack Networking
service agents such as ``neutron-dhcp-agent``, ``neutron-l3-agent``,
``neutron-metering-agent`` or ``neutron-lbaasv2-agent``.
service agents such as ``neutron-dhcp-agent``, ``neutron-l3-agent`` or
A data-forwarding node typically has a network interface with an IP
address on the management network and another interface on the data
@ -46,7 +46,7 @@ agent on each node.
#. Use the NSX Administrator Guide to add the node as a Hypervisor
by using the NSX Manager GUI. Even if your forwarding node has no
VMs and is only used for services agents like ``neutron-dhcp-agent``
or ``neutron-lbaas-agent``, it should still be added to NSX as a
, it should still be added to NSX as a
#. After following the NSX Administrator Guide, use the page for this
@ -348,76 +348,6 @@ The Neutron Metering agent resides beside neutron-l3-agent.
service_plugins = router,metering
Configure Load-Balancer-as-a-Service (LBaaS v2)
.. warning::
Neutron-lbaas is deprecated as of Queens. Load-Balancer-as-a-Service
(LBaaS v2) is now provided by the `Octavia project
<>`_. Please see the FAQ:
For the back end, use either ``Octavia`` or ``HAProxy``.
This example uses Octavia.
**To configure LBaaS V2**
#. Install Octavia using your distribution's package manager.
#. Edit the ``/etc/neutron/neutron_lbaas.conf`` file and change
the ``service_provider`` parameter to enable Octavia:
.. code-block:: ini
service_provider = LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default
#. Edit the ``/etc/neutron/neutron.conf`` file and add the
``service_plugins`` parameter to enable the load-balancing plug-in:
.. code-block:: ini
service_plugins =
If this option is already defined, add the load-balancing plug-in to
the list using a comma as a separator. For example:
.. code-block:: ini
service_plugins = [already defined plugins],
#. Create the required tables in the database:
.. code-block:: console
# neutron-db-manage --subproject neutron-lbaas upgrade head
#. Restart the ``neutron-server`` service.
#. Enable load balancing in the Project section of the dashboard.
.. warning::
Horizon panels are enabled only for LBaaSV1. LBaaSV2 panels are still
being developed.
By default, the ``enable_lb`` option is ``True`` in the ``
.. code-block:: python
'enable_lb': True,
Apply the settings by restarting the web server. You can now view the
Load Balancer management options in the Project view in the dashboard.
Configure Hyper-V L2 agent

@ -7,8 +7,7 @@ you define network connectivity and addressing in the cloud. The
Networking service enables operators to leverage different networking
technologies to power their cloud networking. The Networking service
also provides an API to configure and manage a variety of network
services ranging from L3 forwarding and NAT to load balancing, edge
firewalls, and IPsec VPN.
services ranging from L3 forwarding and NAT to edge firewalls, and IPsec VPN.
For a detailed description of the Networking API abstractions and their
attributes, see the `OpenStack Networking API v2.0
@ -105,60 +104,6 @@ Set these options to configure SSL:
``backlog = 4096``
Number of backlog requests with which to configure the socket.
Load-Balancer-as-a-Service (LBaaS) overview
.. warning::
Neutron-lbaas is deprecated as of Queens. Load-Balancer-as-a-Service
(LBaaS v2) is now provided by the `Octavia project
<>`_. Please see the FAQ:
Load-Balancer-as-a-Service (LBaaS) enables Networking to distribute
incoming requests evenly among designated instances. This distribution
ensures that the workload is shared predictably among instances and
enables more effective use of system resources. Use one of these load
balancing methods to distribute incoming requests:
Round robin
Rotates requests evenly between multiple instances.
Source IP
Requests from a unique source IP address are consistently directed
to the same instance.
Least connections
Allocates requests to the instance with the least number of active
| Feature | Description |
| **Monitors** | LBaaS provides availability monitoring with the |
| | ``ping``, TCP, HTTP and HTTPS GET methods. |
| | Monitors are implemented to determine whether |
| | pool members are available to handle requests. |
| **Management** | LBaaS is managed using a variety of tool sets. |
| | The REST API is available for programmatic |
| | administration and scripting. Users perform |
| | administrative management of load balancers |
| | through either the CLI (``neutron``) or the |
| | OpenStack Dashboard. |
| **Connection limits** | Ingress traffic can be shaped with *connection |
| | limits*. This feature allows workload control, |
| | and can also assist with mitigating DoS (Denial |
| | of Service) attacks. |
| **Session persistence** | LBaaS supports session persistence by ensuring |
| | incoming requests are routed to the same instance |
| | within a pool of multiple instances. LBaaS |
| | supports routing decisions based on cookies and |
| | source IP address. |
Firewall-as-a-Service (FWaaS) overview

@ -1,501 +0,0 @@
.. _config-lbaas:
Load Balancer as a Service (LBaaS)
.. warning::
Neutron-lbaas is deprecated as of Queens. Load-Balancer-as-a-Service
(LBaaS v2) is now provided by the `Octavia project
<>`_. Please see the FAQ:
The Networking service offers a load balancer feature called "LBaaS v2"
through the ``neutron-lbaas`` service plug-in.
LBaaS v2 adds the concept of listeners to the LBaaS v1 load balancers.
LBaaS v2 allows you to configure multiple listener ports on a single load
balancer IP address.
There are two reference implementations of LBaaS v2.
The one is an agent based implementation with HAProxy.
The agents handle the HAProxy configuration and manage the HAProxy daemon.
Another LBaaS v2 implementation, `Octavia
<>`_, has a separate API and
separate worker processes that build load balancers within virtual machines on
hypervisors that are managed by the Compute service. You do not need an agent
for Octavia.
.. warning::
Currently, no migration path exists between v1 and v2 load balancers. If you
choose to switch from v1 to v2, you must recreate all load balancers, pools,
and health monitors.
.. TODO(amotoki): Data mirgation from v1 to v2 is provided in Newton release,
but its usage is not documented enough. It should be added here.
LBaaS v2 Concepts
LBaaS v2 has several new concepts to understand:
.. image:: figures/lbaasv2-diagram.png
:alt: LBaaS v2 layout
Load balancer
The load balancer occupies a neutron network port and has an IP address
assigned from a subnet.
Load balancers can listen for requests on multiple ports. Each one of those
ports is specified by a listener.
A pool holds a list of members that serve content through the load balancer.
Members are servers that serve traffic behind a load balancer. Each member
is specified by the IP address and port that it uses to serve traffic.
Health monitor
Members may go offline from time to time and health monitors divert traffic
away from members that are not responding properly. Health monitors are
associated with pools.
LBaaS v2 has multiple implementations via different service plug-ins. The two
most common implementations use either an agent or the Octavia services. Both
implementations use the `LBaaS v2 API <>`_.
Configuring LBaaS v2 with an agent
#. Add the LBaaS v2 service plug-in to the ``service_plugins`` configuration
directive in ``/etc/neutron/neutron.conf``. The plug-in list is
.. code-block:: console
service_plugins = [existing service plugins],
#. Add the LBaaS v2 service provider to the ``service_provider`` configuration
directive within the ``[service_providers]`` section in
.. code-block:: console
service_provider = LOADBALANCERV2:Haproxy:neutron_lbaas.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default
If you have existing service providers for other networking service
plug-ins, such as VPNaaS or FWaaS, add the ``service_provider`` line shown
above in the ``[service_providers]`` section as a separate line. These
configuration directives are repeatable and are not comma-separated.
#. Select the driver that manages virtual interfaces in
.. code-block:: console
device_driver = neutron_lbaas.drivers.haproxy.namespace_driver.HaproxyNSDriver
interface_driver = INTERFACE_DRIVER
user_group = haproxy
Replace ``INTERFACE_DRIVER`` with the interface driver that the layer-2
agent in your environment uses. For example, ``openvswitch`` for Open
vSwitch or ``linuxbridge`` for Linux bridge.
#. Run the ``neutron-lbaas`` database migration:
.. code-block:: console
neutron-db-manage --subproject neutron-lbaas upgrade head
#. If you have deployed LBaaS v1, **stop the LBaaS v1 agent now**. The v1 and
v2 agents **cannot** run simultaneously.
#. Start the LBaaS v2 agent:
.. code-block:: console
neutron-lbaasv2-agent \
--config-file /etc/neutron/neutron.conf \
--config-file /etc/neutron/lbaas_agent.ini
#. Restart the Network service to activate the new configuration. You are now
ready to create load balancers with the LBaaS v2 agent.
Configuring LBaaS v2 with Octavia
Octavia provides additional capabilities for load balancers, including using a
compute driver to build instances that operate as load balancers.
The `Hands on Lab - Install and Configure OpenStack Octavia
session at the OpenStack Summit in Tokyo provides an overview of Octavia.
The DevStack documentation offers a `simple method to deploy Octavia
and test the service with redundant load balancer instances. If you already
have Octavia installed and configured within your environment, you can
configure the Network service to use Octavia:
#. Add the LBaaS v2 service plug-in to the ``service_plugins`` configuration
directive in ``/etc/neutron/neutron.conf``. The plug-in list is
.. code-block:: console
service_plugins = [existing service plugins],
#. Add the Octavia service provider to the ``service_provider`` configuration
directive within the ``[service_providers]`` section in
.. code-block:: console
service_provider = LOADBALANCERV2:Octavia:neutron_lbaas.drivers.octavia.driver.OctaviaDriver:default
Ensure that the LBaaS v1 and v2 service providers are removed from the
``[service_providers]`` section. They are not used with Octavia. **Verify
that all LBaaS agents are stopped.**
#. Restart the Network service to activate the new configuration. You are now
ready to create and manage load balancers with Octavia.
Add LBaaS panels to Dashboard
The Dashboard panels for managing LBaaS v2 are available starting with the
Mitaka release.
#. Clone the `neutron-lbaas-dashboard repository
and check out the release
branch that matches the installed version of Dashboard:
.. code-block:: console
$ git clone
$ cd neutron-lbaas-dashboard
$ git checkout OPENSTACK_RELEASE
#. Install the Dashboard panel plug-in:
.. code-block:: console
$ python install
#. Copy the ```` file from the
``neutron-lbaas-dashboard/enabled`` directory into the Dashboard
``openstack_dashboard/local/enabled`` directory.
This step ensures that Dashboard can find the plug-in when it enumerates
all of its available panels.
#. Enable the plug-in in Dashboard by editing the ```` file
and setting ``enable_lb`` to ``True`` in the ``OPENSTACK_NEUTRON_NETWORK``
#. If Dashboard is configured to compress static files for better performance
(usually set through ``COMPRESS_OFFLINE`` in ````),
optimize the static files again:
.. code-block:: console
$ ./ collectstatic
$ ./ compress
#. Restart Apache to activate the new panel:
.. code-block:: console
$ sudo service apache2 restart
To find the panel, click on :guilabel:`Project` in Dashboard, then click the
:guilabel:`Network` drop-down menu and select :guilabel:`Load Balancers`.
LBaaS v2 operations
The same neutron commands are used for LBaaS v2 with an agent or with Octavia.
Building an LBaaS v2 load balancer
#. Start by creating a load balancer on a network. In this example, the
``private`` network is an isolated network with two web server instances:
.. code-block:: console
$ neutron lbaas-loadbalancer-create --name test-lb private-subnet
#. You can view the load balancer status and IP address with the
:command:`neutron lbaas-loadbalancer-show` command:
.. code-block:: console
$ neutron lbaas-loadbalancer-show test-lb
| Field | Value |
| admin_state_up | True |
| description | |
| id | 7780f9dd-e5dd-43a9-af81-0d2d1bd9c386 |
| listeners | {"id": "23442d6a-4d82-40ee-8d08-243750dbc191"} |
| | {"id": "7e0d084d-6d67-47e6-9f77-0115e6cf9ba8"} |
| name | test-lb |
| operating_status | ONLINE |
| provider | octavia |
| provisioning_status | ACTIVE |
| tenant_id | fbfce4cb346c4f9097a977c54904cafd |
| vip_address | |
| vip_port_id | 9f8f8a75-a731-4a34-b622-864907e1d556 |
| vip_subnet_id | f1e7827d-1bfe-40b6-b8f0-2d9fd946f59b |
#. Update the security group to allow traffic to reach the new load balancer.
Create a new security group along with ingress rules to allow traffic into
the new load balancer. The neutron port for the load balancer is shown as
``vip_port_id`` above.
Create a security group and rules to allow TCP port 80, TCP port 443, and
all ICMP traffic:
.. code-block:: console
$ neutron security-group-create lbaas
$ neutron security-group-rule-create \
--direction ingress \
--protocol tcp \
--port-range-min 80 \
--port-range-max 80 \
--remote-ip-prefix \
$ neutron security-group-rule-create \
--direction ingress \
--protocol tcp \
--port-range-min 443 \
--port-range-max 443 \
--remote-ip-prefix \
$ neutron security-group-rule-create \
--direction ingress \
--protocol icmp \
Apply the security group to the load balancer's network port using
``vip_port_id`` from the :command:`neutron lbaas-loadbalancer-show`
.. code-block:: console
$ neutron port-update \
--security-group lbaas \
Adding an HTTP listener
#. With the load balancer online, you can add a listener for plaintext
HTTP traffic on port 80:
.. code-block:: console
$ neutron lbaas-listener-create \
--name test-lb-http \
--loadbalancer test-lb \
--protocol HTTP \
--protocol-port 80
This load balancer is active and ready to serve traffic on ````.
#. Verify that the load balancer is responding to pings before moving further:
.. code-block:: console
$ ping -c 4
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=62 time=0.410 ms
64 bytes from icmp_seq=2 ttl=62 time=0.407 ms
64 bytes from icmp_seq=3 ttl=62 time=0.396 ms
64 bytes from icmp_seq=4 ttl=62 time=0.397 ms
--- ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2997ms
rtt min/avg/max/mdev = 0.396/0.402/0.410/0.020 ms
#. You can begin building a pool and adding members to the pool to serve HTTP
content on port 80. For this example, the web servers are ````
and ````:
.. code-block:: console
$ neutron lbaas-pool-create \
--name test-lb-pool-http \
--lb-algorithm ROUND_ROBIN \
--listener test-lb-http \
--protocol HTTP
$ neutron lbaas-member-create \
--name test-lb-http-member-1 \
--subnet private-subnet \
--address \
--protocol-port 80 \
$ neutron lbaas-member-create \
--name test-lb-http-member-2 \
--subnet private-subnet \
--address \
--protocol-port 80 \
#. You can use ``curl`` to verify connectivity through the load balancers to
your web servers:
.. code-block:: console
$ curl
$ curl
$ curl
$ curl
In this example, the load balancer uses the round robin algorithm and the
traffic alternates between the web servers on the backend.
#. You can add a health monitor so that unresponsive servers are removed
from the pool:
.. code-block:: console
$ neutron lbaas-healthmonitor-create \
--name test-lb-http-monitor \
--delay 5 \
--max-retries 2 \
--timeout 10 \
--type HTTP \
--pool test-lb-pool-http
In this example, the health monitor removes the server from the pool if
it fails a health check at two five-second intervals. When the server
recovers and begins responding to health checks again, it is added to
the pool once again.
Adding an HTTPS listener
You can add another listener on port 443 for HTTPS traffic. LBaaS v2 offers
SSL/TLS termination at the load balancer, but this example takes a simpler
approach and allows encrypted connections to terminate at each member server.
#. Start by creating a listener, attaching a pool, and then adding members:
.. code-block:: console
$ neutron lbaas-listener-create \
--name test-lb-https \
--loadbalancer test-lb \
--protocol HTTPS \
--protocol-port 443
$ neutron lbaas-pool-create \
--name test-lb-pool-https \
--lb-algorithm LEAST_CONNECTIONS \
--listener test-lb-https \
--protocol HTTPS
$ neutron lbaas-member-create \
--name test-lb-https-member-1 \
--subnet private-subnet \
--address \
--protocol-port 443 \
$ neutron lbaas-member-create \
--name test-lb-https-member-2 \
--subnet private-subnet \
--address \
--protocol-port 443 \
#. You can also add a health monitor for the HTTPS pool:
.. code-block:: console
$ neutron lbaas-healthmonitor-create \
--name test-lb-https-monitor \
--delay 5 \
--max-retries 2 \
--timeout 10 \
--type HTTPS \
--pool test-lb-pool-https
The load balancer now handles traffic on ports 80 and 443.
Associating a floating IP address
Load balancers that are deployed on a public or provider network that are
accessible to external clients do not need a floating IP address assigned.
External clients can directly access the virtual IP address (VIP) of those
load balancers.
However, load balancers deployed onto private or isolated networks need a
floating IP address assigned if they must be accessible to external clients. To
complete this step, you must have a router between the private and public
networks and an available floating IP address.
You can use the :command:`neutron lbaas-loadbalancer-show` command from the
beginning of this section to locate the ``vip_port_id``. The ``vip_port_id``
is the ID of the network port that is assigned to the load balancer. You can
associate a free floating IP address to the load balancer using
:command:`neutron floatingip-associate`:
.. code-block:: console
$ neutron floatingip-associate FLOATINGIP_ID LOAD_BALANCER_PORT_ID
Setting quotas for LBaaS v2
Quotas are available for limiting the number of load balancers and load
balancer pools. By default, both quotas are set to 10.
You can adjust quotas using the :command:`neutron quota-update` command:
.. code-block:: console
$ neutron quota-update --tenant-id TENANT_UUID --loadbalancer 25
$ neutron quota-update --tenant-id TENANT_UUID --pool 50
A setting of ``-1`` disables the quota for a tenant.
Retrieving load balancer statistics
The LBaaS v2 agent collects four types of statistics for each load balancer
every six seconds. Users can query these statistics with the
:command:`neutron lbaas-loadbalancer-stats` command:
.. code-block:: console
$ neutron lbaas-loadbalancer-stats test-lb
| Field | Value |
| active_connections | 0 |
| bytes_in | 40264557 |
| bytes_out | 71701666 |
| total_connections | 384601 |
The ``active_connections`` count is the total number of connections that were
active at the time the agent polled the load balancer. The other three
statistics are cumulative since the load balancer was last started. For
example, if the load balancer restarts due to a system error or a configuration
change, these statistics will be reset.

@ -151,7 +151,7 @@ Known limitations
If huge pages are not present in the guest, the interface will appear but
will not function.
* Expect performance degradation of services using tap devices: these devices
do not support DPDK. Example services include DVR, FWaaS, or LBaaS.
do not support DPDK. Example services include DVR and FWaaS.
* When the ``ovs_use_veth`` option is set to ``True``, any traffic sent
from a DHCP namespace will have an incorrect TCP checksum.
This means that if ``enable_isolated_metadata`` is set to ``True`` and

@ -21,7 +21,6 @@ Configuration

File diff suppressed because one or more lines are too long


Width:  |  Height:  |  Size: 21 KiB

@ -15,8 +15,8 @@ define network connectivity and addressing in the cloud. The Networking
service enables operators to leverage different networking technologies
to power their cloud networking. The Networking service also provides an
API to configure and manage a variety of network services ranging from L3
forwarding and Network Address Translation (NAT) to load
balancing, perimeter firewalls, and virtual private networks.
forwarding and Network Address Translation (NAT) to perimeter firewalls, and
virtual private networks.
It includes the following components:
@ -166,8 +166,7 @@ VLAN
using VLAN IDs (802.1Q tagged) that correspond to VLANs present in the
physical network. This allows instances to communicate with each other
across the environment. They can also communicate with dedicated servers,
firewalls, load balancers, and other networking infrastructure on the
same layer 2 VLAN.
firewalls, and other networking infrastructure on the same layer 2 VLAN.
VXLAN and GRE are encapsulation protocols that create overlay networks

@ -540,7 +540,7 @@ Extensions can be loaded in two ways:
Service Providers
If your project uses service provider(s) the same way VPNAAS and LBAAS do, you
If your project uses service provider(s) the same way VPNAAS does, you
specify your service provider in your ``project_name.conf`` file like so::

@ -127,7 +127,7 @@ network or a port, making all rules of the policy applied to the corresponding
Neutron resource.
When applied through a network association, policy rules could apply or not
to neutron internal ports (like router, dhcp, load balancer, etc..). The QosRule
to neutron internal ports (like router, dhcp, etc..). The QosRule
base object provides a default should_apply_to_port method which could be
overridden. In the future we may want to have a flag in QoSNetworkPolicyBinding
or QosRule to enforce such type of application (for example when limiting all

@ -27,9 +27,6 @@ Service Extensions
Historically, Neutron supported the following advanced services:
#. **FWaaS** (*Firewall-as-a-Service*): runs as part of the L3 agent.
#. **LBaaS** (*Load-Balancer-as-a-Service*): implemented purely inside
neutron-server, does not interact directly with agents. **Deprecated as of
#. **VPNaaS** (*VPN-as-a-Service*): derives from L3 agent to add
VPNaaS functionality.
@ -47,7 +44,6 @@ consider adding an entry to the dictionary, please be kind and
reach out to your PTL or a member of the drivers team for approval.

@ -24,7 +24,7 @@ Sub-Projects and Specs
The `neutron-specs <>`_
repository is only meant for specs from Neutron itself, and the advanced
services repositories as well. This includes FWaaS, LBaaS, and VPNaaS. Other
services repositories as well. This includes FWaaS and VPNaaS. Other
sub-projects are encouraged to fold their specs into their own devref code
in their sub-project gerrit repositories. Please see additional comments
in the Neutron teams :ref:`section <specs-core-reviewer-team>`

@ -94,7 +94,7 @@ Some notes on the above:
agents and ML2.
* The client includes commands installed server side.
* L3 includes the L3 agent, DVR, Dynamic routing and IPAM.
* Services includes FWaaS, LBaaS, and VPNaaS.
* Services includes FWaaS and VPNaaS.
* Note these areas may change as the project evolves due to code refactoring,
new feature areas, and libification of certain pieces of code.
* Infra means interactions with infra from a neutron perspective

@ -29,8 +29,8 @@ You can see a programmatic example of the exceptions here [3]_.
If your code is in a neutron-\*aas repo, you should run against the tests
for that repo. You may also run against every neutron change, if your service
driver is using neutron interfaces that are not provided by your service
plugin (e.g. loadbalancer/ If you are using only plugin interfaces,
it should be safe to test against only the service repo tests.
plugin (e.g. firewall/ If you are using only plugin
interfaces, it should be safe to test against only the service repo tests.
What Tests To Run
@ -47,11 +47,6 @@ example tempest setup for devstack-gate::
export DEVSTACK_GATE_TEMPEST_REGEX='(?!.*\[.*\bslow\b.*\])((network)|(neutron))'
An example setup for LBaaS::
export DEVSTACK_GATE_TEMPEST_REGEX='(?!.*\[.*\bslow\b.*\])(alancer|SimpleReadOnlyNeutron|'
Third Party CI Voting

@ -69,8 +69,6 @@ names, which were moved out of Neutron: ::
# Arista ML2 driver Models moved to openstack/networking-arista
@ -81,7 +79,7 @@ names, which were moved out of Neutron: ::

@ -6,7 +6,7 @@ Virtual Networking Infrastructure (VNI) and the access layer aspects
of the Physical Networking Infrastructure (PNI) in your OpenStack
environment. OpenStack Networking enables projects to create advanced
virtual network topologies which may include services such as a
firewall, a load balancer, and a virtual private network (VPN).
firewall, and a virtual private network (VPN).
Networking provides networks, subnets, and routers as object abstractions.
Each abstraction has functionality that mimics its physical counterpart:
@ -49,5 +49,5 @@ Each plug-in that Networking uses has its own concepts. While not vital
to operating the VNI and OpenStack environment, understanding these
concepts can help you set up Networking. All Networking installations
use a core plug-in and a security group plug-in (or just the No-Op
security group plug-in). Additionally, Firewall-as-a-Service (FWaaS) and
Load-Balancer-as-a-Service (LBaaS) plug-ins are available.
security group plug-in). Additionally, Firewall-as-a-Service (FWaaS)
is available.

@ -147,8 +147,8 @@ infrastructure.
.. warning::
This option lacks support for self-service (private) networks, layer-3
(routing) services, and advanced services such as
Load-Balancer-as-a-Service (LBaaS) and FireWall-as-a-Service (FWaaS).
(routing) services, and advanced services such as FireWall-as-a-Service
Consider the self-service networks option below if you desire these features.
.. _figure-network1-services:
@ -167,7 +167,7 @@ self-service networks using overlay segmentation methods such
as Virtual Extensible LAN (VXLAN). Essentially, it routes
virtual networks to physical networks using Network Address
Translation (NAT). Additionally, this option provides the foundation for
advanced services such as LBaaS and FWaaS.
advanced services such as FWaaS.
The OpenStack user can create virtual networks without the knowledge
of underlying infrastructure on the data network. This can also include

@ -167,7 +167,7 @@ class ProcessMonitor(object):
:param config: oslo config object with the agent configuration.
:type config: oslo_config.ConfigOpts
:param resource_type: can be dhcp, router, load_balancer, etc.
:param resource_type: can be dhcp, router, etc.
:type resource_type: str
self._config = config

@ -37,12 +37,10 @@ from neutron.conf.agent import common as agent_config
from neutron.conf.agent import dhcp as dhcp_config
LOG = logging.getLogger(__name__)
LB_NS_PREFIX = 'qlbaas-'
'dhcp': [dhcp.NS_PREFIX],
'l3': [namespaces.NS_PREFIX, dvr_snat_ns.SNAT_NS_PREFIX,
'lbaas': [LB_NS_PREFIX],
NETSTAT_PIDS_REGEX = re.compile(r'.* (?P<pid>\d{2,6})/.*')

@ -33,7 +33,7 @@ netns_opts = [
help=_('Delete the namespace by removing all devices.')),
choices=['dhcp', 'l3', 'lbaas'],
choices=['dhcp', 'l3'],
help=_('Cleanup resources of a specific agent type only.')),

@ -145,31 +145,6 @@ rules = [
# TODO(amotoki): Remove LBaaS related policies once neutron-lbaas
# is retired.
'List load balancers on an LBaaS v2 agent',
'method': 'GET',
'path': '/agents/{agent_id}/agent-loadbalancers',
'List LBaaS v2 agents hosting a load balancer',
'method': 'GET',
'path': ('/lbaas/loadbalancers/{load_balancer_id}/'

@ -53,7 +53,6 @@ class AgentSchedulerDbMixin(agents_db.AgentDbMixin):
agent_notifiers = {
constants.AGENT_TYPE_DHCP: None,
constants.AGENT_TYPE_L3: None,

@ -18,6 +18,8 @@ VPNAAS_TABLES = ['vpnservices', 'ipsecpolicies', 'ipsecpeercidrs',
'ipsec_site_connections', 'cisco_csr_identifier_map',
# Neutron-lbaas is retired, but we need to keep this for the models until
# we decide to remove the tables.
LBAAS_TABLES = ['vips', 'sessionpersistences', 'pools', 'healthmonitors',
'poolstatisticss', 'members', 'poolloadbalanceragentbindings',

@ -140,11 +140,11 @@ def check_oslo_i18n_wrapper(logical_line, filename, noqa):
"""N340 - Check for neutron.i18n usage.
Okay(neutron/foo/ from neutron._i18n import _
Okay(neutron_lbaas/foo/ from neutron_lbaas._i18n import _
Okay(neutron_fwaas/foo/ from neutron_fwaas._i18n import _
N340(neutron/foo/ from neutron.i18n import _
N340(neutron_lbaas/foo/ from neutron_lbaas.i18n import _
N340(neutron_lbaas/foo/ from neutron.i18n import _
N340(neutron_lbaas/foo/ from neutron._i18n import _
N340(neutron_fwaas/foo/ from neutron_fwaas.i18n import _
N340(neutron_fwaas/foo/ from neutron.i18n import _
N340(neutron_fwaas/foo/ from neutron._i18n import _
Okay(neutron/foo/ from neutron.i18n import _ # noqa

@ -121,7 +121,7 @@ class V2Controller(object):
# if collection exists in the extension to service plugins map then
# we are assuming that collection is the service plugin and
# needs to be remapped.
# Example: https://neutron.endpoint/v2.0/lbaas/loadbalancers
# Example: https://neutron.endpoint/v2.0/fwaas/firewall_groups
if (remainder and

@ -19,8 +19,6 @@ from neutron_lib.plugins import constants as p_const
# Maps extension alias to service type that
# can be implemented by the core plugin.
'lbaas': p_const.LOADBALANCER,
'lbaasv2': p_const.LOADBALANCERV2,
'fwaas': p_const.FIREWALL,
'vpnaas': p_const.VPN,
'metering': p_const.METERING,

@ -123,9 +123,6 @@ class TestNetnsCleanup(base.BaseTestCase):
def test_eligible_for_deletion_fip_namespace(self):
self._test_eligible_for_deletion_helper('fip-', False, True, True)
def test_eligible_for_deletion_lbaas_namespace(self):
self._test_eligible_for_deletion_helper('qlbaas-', False, True, True)
def test_eligible_for_deletion_snat_namespace(self):
self._test_eligible_for_deletion_helper('snat-', False, True, True)

@ -84,7 +84,7 @@ class DummyServicePlugin(service_base.ServicePluginBase):
"""This is a simple plugin for managing instances of a fictional 'dummy'
service. This plugin is provided as a proof-of-concept of how
advanced service might leverage the service type extension.
Ideally, instances of real advanced services, such as load balancing
Ideally, instances of real advanced services, such as firewall
or VPN will adopt a similar solution.

@ -13,8 +13,6 @@
# License for the specific language governing permissions and limitations
# under the License.
import copy
from datetime import datetime
import time
from neutron_lib.api.definitions import agent as agent_apidef
@ -38,8 +36,6 @@ L3_HOSTA = 'hosta'
DHCP_HOSTA = 'hosta'
L3_HOSTB = 'hostb'
DHCP_HOSTC = 'hostc'
LBAAS_HOSTA = 'hosta'
LBAAS_HOSTB = 'hostb'
class AgentTestExtensionManager(object):
@ -72,7 +68,7 @@ class AgentDBTestMixIn(object):
self.assertEqual(expected_res_status, agent_res.status_int)
return agent_res
def _register_agent_states(self, lbaas_agents=False):
def _register_agent_states(self):
"""Register two L3 agents and two DHCP agents."""
l3_hosta = helpers._get_l3_agent_dict(
@ -85,28 +81,7 @@ class AgentDBTestMixIn(object):
res = [l3_hosta, l3_hostb, dhcp_hosta, dhcp_hostc]
if lbaas_agents:
lbaas_hosta = {
'binary': 'neutron-loadbalancer-agent',
'host': LBAAS_HOSTA,
'configurations': {'device_drivers': ['haproxy_ns']},
'agent_type': constants.AGENT_TYPE_LOADBALANCER}
lbaas_hostb = copy.deepcopy(lbaas_hosta)
lbaas_hostb['host'] = LBAAS_HOSTB
callback = agents_db.AgentExtRpcCallback()
agent_state={'agent_state': lbaas_hosta},
agent_state={'agent_state': lbaas_hostb},
res += [lbaas_hosta, lbaas_hostb]
return res
return [l3_hosta, l3_hostb, dhcp_hosta, dhcp_hostc]
def _register_dvr_agents(self):
dvr_snat_agent = helpers.register_l3_agent(

@ -60,20 +60,20 @@ class ServiceTypeManagerTestCase(testlib_api.SqlTestCase):
def test_service_provider_driver_not_unique(self):
self._set_override([constants.LOADBALANCER + ':lbaas:driver'])
prov = {'service_type': constants.LOADBALANCER,
self._set_override([constants.FIREWALL + ':fwaas:driver'])
prov = {'service_type': constants.FIREWALL,
'name': 'name2',
'driver': 'driver',
'default': False}
self.manager.config['LOADBALANCER'].add_provider, prov)
self.manager.config['FIREWALL'].add_provider, prov)
def test_get_service_providers(self):
"""Test that get_service_providers filters correctly."""
[constants.LOADBALANCER +
[constants.VPN +
constants.FIREWALL +
ctx = context.get_admin_context()
@ -82,7 +82,7 @@ class ServiceTypeManagerTestCase(testlib_api.SqlTestCase):
res = self.manager.get_service_providers(
self.assertEqual(1, len(res))
@ -96,21 +96,21 @@ class ServiceTypeManagerTestCase(testlib_api.SqlTestCase):
[constants.LOADBALANCER +
constants.LOADBALANCER +
[constants.FIREWALL +
constants.FIREWALL +
def test_get_default_provider(self):
self._set_override([constants.LOADBALANCER +
self._set_override([constants.FIREWALL +
# can pass None as a context
p = self.manager.get_default_service_provider(None,
self.assertEqual({'service_type': constants.LOADBALANCER,
'name': 'lbaas1',
self.assertEqual({'service_type': constants.FIREWALL,
'name': 'fwaas1',
'driver': 'driver_path',
'default': True}, p)
@ -148,24 +148,24 @@ class ServiceTypeManagerTestCase(testlib_api.SqlTestCase):
for td in test_data}, names_by_id)
def test_add_resource_association(self):
self._set_override([constants.LOADBALANCER +
self._set_override([constants.FIREWALL +
ctx = context.get_admin_context()
1, servicetype_obj.ProviderResourceAssociation.count(ctx))
def test_invalid_resource_association(self):
self._set_override([constants.LOADBALANCER +
self._set_override([constants.FIREWALL +
ctx = context.get_admin_context()
@ -232,7 +232,7 @@ class ServiceTypeManagerExtTestCase(ServiceTypeExtensionTestCaseBase):
self.service_providers = mock.patch.object(
provconf.NeutronModule, 'service_providers').start()
service_providers = [
constants.LOADBALANCER + ':lbaas:driver_path',
constants.FIREWALL + ':fwaas:driver_path',
dp.DUMMY_SERVICE_TYPE + ':dummy:dummy_dr'
self.service_providers.return_value = service_providers

@ -3096,30 +3096,6 @@ class TestOvsDvrNeutronAgent(object):
def test_port_bound_for_dvr_with_lbaas_vip_ports(self):
def test_port_bound_for_dvr_with_lbaasv2_vip_ports(self):
def test_port_bound_for_dvr_with_dhcp_ports(self):
@ -3478,20 +3454,6 @@ class TestOvsDvrNeutronAgent(object):
device_owner=DEVICE_OWNER_COMPUTE, ip_version=n_const.IP_VERSION_6)
def test_treat_devices_removed_for_dvr_with_lbaas_vip_ports(self):
def test_treat_devices_removed_for_dvr_with_lbaasv2_vip_ports(self):
def test_treat_devices_removed_for_dvr_with_dhcp_ports(self):

@ -1480,14 +1480,6 @@ class TestMl2PortsV2(test_plugin.TestPortsV2, Ml2PluginV2TestCase):
def test_check_if_compute_port_serviced_by_dvr(self):
def test_check_if_lbaas_vip_port_serviced_by_dvr(self):
def test_check_if_lbaasv2_vip_port_serviced_by_dvr(self):
def test_check_if_dhcp_port_serviced_by_dvr(self):

@ -40,10 +40,10 @@ class ParseServiceProviderConfigurationTestCase(base.BaseTestCase):
self.assertEqual([], providers)
def test_parse_single_service_provider_opt(self):
self._set_override([constants.LOADBALANCER +
expected = {'service_type': constants.LOADBALANCER,
'name': 'lbaas',
self._set_override([constants.FIREWALL +
expected = {'service_type': constants.FIREWALL,
'name': 'fwaas',
'driver': 'driver_path',
'default': False}
res = provconf.parse_service_provider_opt()
@ -51,10 +51,10 @@ class ParseServiceProviderConfigurationTestCase(base.BaseTestCase):
self.assertEqual([expected], res)
def test_parse_single_default_service_provider_opt(self):
self._set_override([constants.LOADBALANCER +
expected = {'service_type': constants.LOADBALANCER,
'name': 'lbaas',
self._set_override([constants.FIREWALL +
expected = {'service_type': constants.FIREWALL,
'name': 'fwaas',
'driver': 'driver_path',
'default': True}
res = provconf.parse_service_provider_opt()
@ -62,10 +62,10 @@ class ParseServiceProviderConfigurationTestCase(base.BaseTestCase):
self.assertEqual([expected], res)
def test_parse_multi_service_provider_opt(self):
self._set_override([constants.LOADBALANCER +
constants.LOADBALANCER + ':name1:path1',
constants.LOADBALANCER +
self._set_override([constants.FIREWALL +
constants.FIREWALL + ':name1:path1',
constants.FIREWALL +
res = provconf.parse_service_provider_opt()
# This parsing crosses repos if additional projects are installed,
@ -73,18 +73,18 @@ class ParseServiceProviderConfigurationTestCase(base.BaseTestCase):
self.assertGreaterEqual(len(res), 3)
def test_parse_service_provider_invalid_format(self):
self._set_override([constants.LOADBALANCER +
self._set_override([constants.FIREWALL +
self.assertRaises(n_exc.Invalid, provconf.parse_service_provider_opt)
self._set_override([constants.LOADBALANCER +
self._set_override([constants.FIREWALL +
self.assertRaises(n_exc.Invalid, provconf.parse_service_provider_opt)
def test_parse_service_provider_name_too_long(self):
name = 'a' * 256