linuxbridge agent needs ability to use pre-configured physical network bridges (nova-related)

[Robert Kukura]

The linuxbridge agent currently creates a bridge for each physical network used as a flat network, moving any existing IP address from the interface to the newly created bridge. This is very helpful in some cases, but there are other cases where the ability to use a pre-existing bridge is needed. For instance, the same physical network might need to be bridged for other purposes, or the agent moving the system's IP might not be desired.

I suggest we add a physical_bridge_mappings configuration variable, similar to that used by the openvswitch agent, alongside the current physical_interface_mappings variable. When a bridge for a flat network is needed, the bridge mappings would be checked first. If a bridge mapping for the physical network exists, it would be used. If not, the interface mapping would be used and a bridge for the interface would be created automatically. Sub-interfaces and bridges for VLAN networks would continue to work as they do now, created by the agent using the interface mappings.

[Li Ma (nick-ma-z)]

A BP to implement bridge-mapping is working.

https://blueprints.launchpad.net/neutron/+spec/phy-net-bridge-mapping

[Li Ma (nick-ma-z)]

Nova hard-code 'brq' + net-id as bridge name in libvirt configuration, so it is impossible for neutron to define bridge name for instances.

nova/network/neutronv2/api.py:

def _nw_info_build_network(self, port, networks, subnets):

1530 elif vif_type == network_model.VIF_TYPE_BRIDGE:
1531 bridge = "brq" + port['network_id']

So, when Neutron loads a pre-existed user-defined bridge called 'br-eth1' and would like to let it connect the instances, it will fail because Nova writes 'brq-net-id' into libvirt conf file.

A good design is that, when creating port, Neutron sends bridge name back to Nova and Nova just makes it effective (write it into libvirt).

[Li Ma (nick-ma-z)]

This feature is related with nova-neutron interaction.

If nova calls neutron restful api, it is difficult to append 'bridge-to-be-attached' info into api response. For example, a parameter called 'physical bridge' may be added to Port object in neutron or Port-binding dict.

However, if nova calls neutron rpc, it is easy to append any info to nova.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/209006
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=bd734811753a99d61e30998c734e465a8d507b8f
Submitter: Jenkins
Branch: master

commit bd734811753a99d61e30998c734e465a8d507b8f
Author: Nick <email address hidden>
Date: Sun Jul 19 22:41:27 2015 +0800

    Implement external physical bridge mapping in linuxbridge

    In some deployment scenario, it is not allowed to remove system
    ethernet configuration from physical interface to newly-created
    physical bridge by neutron due to some IT regulations.
    End-users require to take advantage of the pre-existed(user-defined)
    physical bridge to connect tap devices for neutron.

    Closes-Bug: #1105488
    Implements: blueprint phy-net-bridge-mapping
    DocImpact

    Change-Id: Ia0eaa6233d8da93da32e86404b15184b77937d0a

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: feature/pecan
Review: https://review.openstack.org/224334

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: feature/pecan
Review: https://review.openstack.org/224357

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/224357
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=fdc3431ccd219accf6a795079d9b67b8656eed8e
Submitter: Jenkins
Branch: feature/pecan

commit fe236bdaadb949661a0bfb9b62ddbe432b4cf5f1
Author: Miguel Angel Ajo <email address hidden>
Date: Thu Sep 3 15:40:12 2015 +0200

    No network devices on network attached qos policies

    Network devices, like internal router legs, or dhcp ports
    should not be affected by bandwidth limiting rules.

    This patch disables application of network attached policies
    to network/neutron owned ports.

    Closes-bug: #1486039
    DocImpact

    Change-Id: I75d80227f1e6c4b3f5fa7762b8dc3b0c0f1abd46

commit db4a06f7caa20a4c7879b58b20e95b223ed8eeaf
Author: Ken'ichi Ohmichi <email address hidden>
Date: Wed Sep 16 10:04:32 2015 +0000

    Use tempest-lib's token_client

    Now tempest-lib provides token_client modules as library and the
    interface is stable. So neutron repogitory doesn't need to contain
    these modules.
    This patch makes neutron use tempest-lib's token_client and removes
    the own modules for the maintenance.

    Change-Id: Ieff7eb003f6e8257d83368dbc80e332aa66a156c

commit 78aed58edbe6eb8a71339c7add491fe9de9a0546
Author: Jakub Libosvar <email address hidden>
Date: Thu Aug 13 09:08:20 2015 +0000

    Fix establishing UDP connection

    Previously, in establish_connection() for UDP protocol data were sent
    but never read on peer socket. That lead to successful read on peer side
    if this connection was filtered. Having constant testing string masked
    this issue as we can't distinguish to which test of connectivity data
    belong.

    This patch makes unique data string per test_connectivity() and
    also makes establish_connection() to create an ASSURED entry in
    conntrack table. Finally, in last test after firewall filter was
    removed, connection is re-established in order to avoid troubles with
    terminated processes or TCP continuing sending packets which weren't
    successfully delivered.

    Closes-Bug: 1478847
    Change-Id: I2920d587d8df8d96dc1c752c28f48ba495f3cf0f

commit e6292fcdd6262434a7b713ad8802db6bc8a6d3dc
Author: YAMAMOTO Takashi <email address hidden>
Date: Wed Sep 16 13:20:51 2015 +0900

    ovsdb: Fix a few docstring

    Change-Id: I53e1e21655b28fe5da60e58aeeb7cbbd103ae014

commit c22949a4449d96a67caa616290cf76b67b182917
Author: fumihiko kakuma <email address hidden>
Date: Wed Sep 16 11:52:59 2015 +0900

    Remove requirements.txt for the ofagent mechanism driver

    It is no longer used.

    Related-Blueprint: core-vendor-decomposition
    https://blueprints.launchpad.net/neutron/+spec/core-vendor-decomposition

    Change-Id: Ib31fb3febf8968e50d86dd66e1e6e1ea2313f8ac

commit d1d4de19d85f961d388c91e70f31b3bafec418c5
Author: Kevin Benton <email address hidden>
Date: Thu Sep 3 20:25:57 2015 -0700

    Always return iterables in L3 get_candidates

    The caller of this function expects iterables.

    Closes-Bug: #1494996
    Change-Id: I3d103e63f4e127a77268502415c0ddb0d804b54a

commit 1ad6ac448067306...

[OpenStack Infra (hudson-openstack)]

Change abandoned by Doug Wiegley (<email address hidden>) on branch: feature/pecan
Review: https://review.openstack.org/224334

[Nelson Lago (lago)]

I'd like to point out that this seems to be implemented correctly in neutron, but nova also needs to be modified accordingly. There are two places in nova where the bridge name is automatically determined:

1. nova/network/neutronv2/api.py - line 1596
2. nova/network/linux_net.py - line 1947

Apparently, only the first one is actually executed, at least in my configuration (provider networks with linux-bridge), but it prevents this new feature from working.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/447150
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=1b987be2b55558dcc276fcfc8af6e39f8b6bac16
Submitter: Jenkins
Branch: master

commit 1b987be2b55558dcc276fcfc8af6e39f8b6bac16
Author: Kevin Benton <email address hidden>
Date: Fri Mar 17 14:56:36 2017 -0700

    Use vif_type='tap' for LinuxBridge for consistency

    This adjusts the Linux Bridge mechanism driver to return
    the 'tap' VIF type to Nova so the Linux Bridge agent is
    responsible for plugging all ports into bridges.

    This completely eliminates all of the work Nova was doing with
    regard to bridges so we now have one consistent path how ports
    (both compute and dhcp/l3) are connected into Linux Bridge
    networks. Both Nova and the DHCP/L3 agents will now just create
    a device and leave wiring to bridges to be completely the
    responsibility of the L2 agent.

    In order to preserve backwards compatibiliy with Ocata agents
    that won't touch compute ports, we only report back vif_type='tap'
    if the agent has a report_state value showing that it wires compute
    ports.

    This will also solve a longstanding bug (bug #1105488) that
    is preventing Nova instances from using custom bridge mappings
    since the agent will be guaranteed to be responsible for the
    connection to the bridge.

    Depends-On: I075595158d8f3b5a6811c4794aa7b91912940db5

    Related-Bug: #1617447
    Closes-Bug: #1673910
    Closes-Bug: #1105488
    Change-Id: I23c5faaeab69aede1fd038a36f4a0b8f928498ce

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 11.0.0.0b2 development milestone.

[Matt Riedemann (mriedem)]

This was reverted in: https://review.openstack.org/#/c/472365/

So I'm going to re-open this.

[Sam Morrison (sorrison)]

Have stumbled across this bug in our attempt to move from multiple provider networks to a single routed provider network - https://docs.openstack.org/ocata/networking-guide/config-routed-networks.html.

We can do this with minor SQL changes but we come unstuck with the bridge names. In nova we have currently got a custom config option that maps network_ids to brdige device names which makes things work nicely.

Just wondering if there is any progress on this patch that has been reverted or I should propose my little patch that just adds an extra nova config option?

[Sam Morrison (sorrison)]

I also found a related issue which I created a new bug for https://bugs.launchpad.net/neutron/+bug/1761070

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

Neutron bug closed due to lack of activity, please feel free to reopen if needed.