[doc] Add LXB scenario documentation

Since LXB was installed by default, we never had it described
explicitly as all other examples were reffering to it. Now when we've
switched to OVN as default driver, we should describe path for LXB
as well as make adjustments to reflect new defaults for neutron role.

Change-Id: I98011dbbe3a3c2f6992e1a150e5ec97642398fc0

doc/source/app-linuxbridge.rst

@@ -0,0 +1,202 @@
+=============================
+Scenario - Using Linux Bridge
+=============================
+
+Overview
+~~~~~~~~
+
+Operators can choose to utilize Linux Bridges instead of Open vSwitch for the
+neutron ML2 agent. This document outlines how to set it up in your environment.
+
+.. warning::
+
+    LinuxBridge driver is considered as experimental in Neutron and is
+    discouraged for usage as of today.
+
+
+Prerequisites
+~~~~~~~~~~~~~
+
+All compute nodes must have bridges configured:
+
+- ``br-mgmt`` - Bridge is used to wire LXC containers. Can be regular interface
+  for bare metal deployments
+- ``br-vlan`` (optional - used for vlan networks). Can be regular interface.
+- ``br-vxlan`` (optional - used for vxlan tenant networks). Can be regular
+  interface.
+- ``br-storage`` (optional - used for certain storage devices). It's also
+  used to wire LXC containers. Can be regular interface for bare metal nodes.
+
+For more information see:
+`<https://docs.openstack.org/project-deploy-guide/openstack-ansible/newton/targethosts-networkconfig.html>`_
+
+
+Configuring bridges (Linux Bridge)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following is an example of how to configure a bridge (example: ``br-mgmt``)
+with a Linux Bridge on Ubuntu 16.04 LTS:
+
+``/etc/network/interfaces``
+
+.. code-block:: shell-session
+
+    auto lo
+    iface lo inet loopback
+
+    # Management network
+    auto eth0
+    iface eth0 inet manual
+
+    # VLAN network
+    auto eth1
+    iface eth1 inet manual
+
+    source /etc/network/interfaces.d/*.cfg
+
+``/etc/network/interfaces.d/br-mgmt.cfg``
+
+.. code-block:: shell-session
+
+    # OpenStack Management network bridge
+    auto br-mgmt
+    iface br-mgmt inet static
+      bridge_stp off
+      bridge_waitport 0
+      bridge_fd 0
+      bridge_ports eth0
+      address MANAGEMENT_NETWORK_IP
+      netmask 255.255.255.0
+
+One ``br-<type>.cfg`` is required for each bridge. VLAN interfaces can be used
+to back the ``br-<type>`` bridges if there are limited physical adapters on the
+system.
+
+OpenStack-Ansible user variables
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Specify provider network definitions in your
+``/etc/openstack_deploy/openstack_user_config.yml`` that define
+one or more Neutron provider bridges and related configuration:
+
+.. code-block:: yaml
+
+  - network:
+      container_bridge: "br-provider"
+      container_type: "veth"
+      type: "vlan"
+      range: "101:200,301:400"
+      net_name: "physnet1"
+      network_interface: "bond1"
+      group_binds:
+        - neutron_linuxbridge_agent
+  - network:
+      container_bridge: "br-provider2"
+      container_type: "veth"
+      type: "vlan"
+      range: "203:203,467:500"
+      net_name: "physnet2"
+      network_interface: "bond2"
+      group_binds:
+        - neutron_linuxbridge_agent
+
+When using ``flat`` provider networks, modify the network type accordingly:
+
+.. code-block:: yaml
+
+  - network:
+      container_bridge: "br-publicnet"
+      container_type: "veth"
+      type: "flat"
+      net_name: "flat"
+      group_binds:
+        - neutron_linuxbridge_agent
+
+Specify an overlay network definition in your
+``/etc/openstack_deploy/openstack_user_config.yml`` that defines
+overlay network-related configuration:
+
+.. note::
+
+  The bridge name should correspond to a pre-created Linux bridge.
+
+.. code-block:: yaml
+
+  - network:
+      container_bridge: "br-vxlan"
+      container_type: "veth"
+      container_interface: "eth10"
+      ip_from_q: "tunnel"
+      type: "vxlan"
+      range: "1:1000"
+      net_name: "vxlan"
+      group_binds:
+        - neutron_linuxbridge_agent
+
+Set the following user variables in your
+``/etc/openstack_deploy/user_variables.yml``:
+
+.. code-block:: yaml
+
+  neutron_plugin_type: ml2.lxb
+
+  neutron_ml2_drivers_type: "flat,vlan,vxlan"
+  neutron_plugin_base:
+    - router
+    - metering
+
+The overrides are instructing Ansible to deploy the LXB mechanism driver and
+associated LXB components. This is done by setting ``neutron_plugin_type``
+to ``ml2.lxb``.
+
+The ``neutron_ml2_drivers_type`` override provides support for all common type
+drivers supported by LXB.
+
+The ``neutron_plugin_base`` is used to defined list of plugins that will be
+enabled.
+
+If provider network overrides are needed on a global or per-host basis,
+the following format can be used in ``user_variables.yml`` or per-host
+in ``openstack_user_config.yml``.
+
+.. note::
+
+  These overrides are not normally required when defining global provider
+  networks in the ``openstack_user_config.yml`` file.
+
+.. code-block:: yaml
+
+  # When configuring Neutron to support vxlan tenant networks and
+  # vlan provider networks the configuration may resemble the following:
+  neutron_provider_networks:
+    network_types: "vxlan"
+    network_vxlan_ranges: "1:1000"
+    network_vlan_ranges: "physnet1:102:199"
+    network_mappings: "physnet1:br-provider"
+    network_interface_mappings: "br-provider:bond1"
+
+  # When configuring Neutron to support only vlan tenant networks and
+  # vlan provider networks the configuration may resemble the following:
+  neutron_provider_networks:
+    network_types: "vlan"
+    network_vlan_ranges: "physnet1:102:199"
+    network_mappings: "physnet1:br-provider"
+    network_interface_mappings: "br-provider:bond1"
+
+  # When configuring Neutron to support multiple vlan provider networks
+  # the configuration may resemble the following:
+  neutron_provider_networks:
+    network_types: "vlan"
+    network_vlan_ranges: "physnet1:102:199,physnet2:2000:2999"
+    network_mappings: "physnet1:br-provider,physnet2:br-provider2"
+    network_interface_mappings: "br-provider:bond1,br-provider2:bond2"
+
+  # When configuring Neutron to support multiple vlan and flat provider
+  # networks the configuration may resemble the following:
+  neutron_provider_networks:
+    network_flat_networks: "*"
+    network_types: "vlan"
+    network_vlan_ranges: "physnet1:102:199,physnet2:2000:2999"
+    network_mappings: "physnet1:br-provider,physnet2:br-provider2"
+    network_interface_mappings: "br-provider:bond1,br-provider2:bond2"
+

doc/source/app-openvswitch-dpdk.rst

@@ -479,6 +479,9 @@ and DPDK support:
 
   neutron_plugin_type: ml2.ovs
   neutron_ml2_drivers_type: "vlan"
+  neutron_plugin_base:
+    - router
+    - metering
 
   # Enable DPDK support
   ovs_dpdk_support: True

doc/source/app-openvswitch-dvr.rst

@@ -125,6 +125,9 @@ Set the following user variables in your
   neutron_plugin_type: ml2.ovs.dvr
 
   neutron_ml2_drivers_type: "flat,vlan,vxlan"
+  neutron_plugin_base:
+    - router
+    - metering
 
 The overrides are instructing Ansible to deploy the OVS mechanism driver and
 associated OVS and DVR components. This is done by setting ``neutron_plugin_type``

doc/source/app-openvswitch.rst

@@ -123,10 +123,6 @@ One ``br-<type>.cfg`` is required for each bridge. VLAN interfaces can be used
 to back the ``br-<type>`` bridges if there are limited physical adapters on the
 system.
 
-**Warning**: There is a bug in Ubuntu 16.04 LTS where the Open vSwitch service
-won't start properly when using systemd. The bug and workaround are discussed
-here: `<http://www.opencloudblog.com/?p=240>`_
-
 
 OpenStack-Ansible user variables
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -214,6 +210,9 @@ Set the following user variables in your
   neutron_plugin_type: ml2.ovs
 
   neutron_ml2_drivers_type: "flat,vlan,vxlan"
+  neutron_plugin_base:
+    - router
+    - metering
 
 The overrides are instructing Ansible to deploy the OVS mechanism driver and
 associated OVS components. This is done by setting ``neutron_plugin_type``
@@ -222,6 +221,9 @@ to ``ml2.ovs``.
 The ``neutron_ml2_drivers_type`` override provides support for all common type
 drivers supported by OVS.
 
+The ``neutron_plugin_base`` is used to defined list of plugins that will be
+enabled.
+
 If provider network overrides are needed on a global or per-host basis,
 the following format can be used in ``user_variables.yml`` or per-host
 in ``openstack_user_config.yml``.

doc/source/configure-network-services.rst

@@ -25,52 +25,6 @@ Firewall service (optional)
 The following procedure describes how to modify the
 ``/etc/openstack_deploy/user_variables.yml`` file to enable FWaaS.
 
-Deploying FWaaS v1
-------------------
-
-.. note::
-
-  The FWaaS v1 API is deprecated upstream. While FWaaS v1.0 is still
-  maintained, new features will be implemented in FWaaS v2.0 API.
-
-#. Override the default list of neutron plugins to include
-   ``firewall``:
-
-   .. code-block:: yaml
-
-      neutron_plugin_base:
-        - firewall
-        - ...
-
-#. ``neutron_plugin_base`` is as follows:
-
-   .. code-block:: yaml
-
-      neutron_plugin_base:
-         - router
-         - firewall
-         - vpnaas
-         - metering
-         - qos
-
-#. Execute the neutron install playbook in order to update the configuration:
-
-   .. code-block:: shell-session
-
-       # cd /opt/openstack-ansible/playbooks
-       # openstack-ansible os-neutron-install.yml
-
-#. Execute the horizon install playbook to show the FWaaS panels:
-
-   .. code-block:: shell-session
-
-       # cd /opt/openstack-ansible/playbooks
-       # openstack-ansible os-horizon-install.yml
-
-The FWaaS default configuration options may be changed through the
-`conf override`_ mechanism using the ``neutron_neutron_conf_overrides``
-dict.
-
 Deploying FWaaS v2
 ------------------
 

doc/source/index.rst

@@ -6,6 +6,7 @@ Neutron role for OpenStack-Ansible
    :maxdepth: 2
 
    configure-network-services.rst
+   app-linuxbridge.rst
    app-openvswitch.rst
    app-openvswitch-asap.rst
    app-openvswitch-dvr.rst