ovn-chassis not adding interface to bridge

Bug #1883244 reported by Frode Nordahl
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Charm Helpers
Fix Released
High
Frode Nordahl
charm-ovn-chassis
Fix Released
High
Frode Nordahl
charm-ovn-dedicated-chassis
Fix Released
High
Frode Nordahl

Bug Description

Charm does not add interface to bridge when adding bond interface by name to `bridge-interface-mappings` configuration option.

However if you list the MAC addresses of one of the underlying interfaces it resolves this into the bond name and successfully adds it to the bridge.

The offending code appears to be these lines in charm-helpers:
https://github.com/juju/charm-helpers/blob/1f9ff78eac35a4d5307371f22e16b41c80bd9b4f/charmhelpers/contrib/openstack/context.py#L2770-L2780

Since the bond interface is not an actual physical interface it will not, and should not, be in the mac-ifname map. I guess we need some special handling.

Frode Nordahl (fnordahl)
Changed in charm-helpers:
status: New → Triaged
Changed in charm-ovn-chassis:
status: New → Triaged
Changed in charm-ovn-dedicated-chassis:
status: New → Triaged
Changed in charm-helpers:
importance: Undecided → High
Changed in charm-ovn-chassis:
importance: Undecided → High
Changed in charm-ovn-dedicated-chassis:
importance: Undecided → High
Changed in charm-helpers:
assignee: nobody → Frode Nordahl (fnordahl)
Changed in charm-ovn-chassis:
assignee: nobody → Frode Nordahl (fnordahl)
Changed in charm-ovn-dedicated-chassis:
assignee: nobody → Frode Nordahl (fnordahl)
Changed in charm-ovn-chassis:
milestone: none → 20.08
Changed in charm-ovn-dedicated-chassis:
milestone: none → 20.08
description: updated
Frode Nordahl (fnordahl)
description: updated
Revision history for this message
Ian Marsh (drulgaard) wrote :

I can confirm this behaviour on a deployment using VLANs on the bond0 interface to separate management and provider traffic; in our case, we're trying to map br-ex to bond0.801, and no br-ex bridge is created.

Note that the workaround of using MAC addresses instead does not help us, as bond0 and it's VLAN sub-interfaces all have the same MAC address.

Revision history for this message
Frode Nordahl (fnordahl) wrote :

Use a mac address of one of the physical interfaces the bond is made up of. The code will find the name of the main bond from that and add it to the bridge.

Note that even when you want to use specific vlans for external networking you should still add the main interface to the bridge and not a subinterface.

There is a guide for using vlans from one interface on host and in OVS simultaneously in the OpenStack Charms Deployment Guide [0].

0: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/app-bridge-interface-configuration.html

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to charm-ovn-chassis (master)

Fix proposed to branch: master
Review: https://review.opendev.org/735415

Changed in charm-ovn-chassis:
status: Triaged → In Progress
Changed in charm-ovn-dedicated-chassis:
status: Triaged → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to charm-ovn-dedicated-chassis (master)

Fix proposed to branch: master
Review: https://review.opendev.org/735416

Revision history for this message
Frode Nordahl (fnordahl) wrote :
Changed in charm-helpers:
status: Triaged → In Progress
Revision history for this message
Frode Nordahl (fnordahl) wrote :

For anyone following along I have provided provisional charms built with the fix [0][1].

Please note that if you are upgrading you may need to reset the charms virtual environment. This is due to the charmhelpers provided in the provisional charm appears to have the same version number as the one already installed in the virtual environment, while it in reality is different.

You can reset the virtual environment by removing it prior to doing the charm upgrade, it is located in /var/lib/juju/agents/unit-ovn-*chassis-?/.venv on the units.

This will of course not be necessary when the fix is released into the charms in the charm store.

0: cs:~fnordahl/ovn-chassis-bug1883244
1: cs:~fnordahl/ovn-dedicated-chassis-bug1883244

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to charm-ovn-chassis (master)

Reviewed: https://review.opendev.org/735415
Committed: https://git.openstack.org/cgit/x/charm-ovn-chassis/commit/?id=915464e175f79964446b46ad860e06860f1f66a8
Submitter: Zuul
Branch: master

commit 915464e175f79964446b46ad860e06860f1f66a8
Author: Frode Nordahl <email address hidden>
Date: Sat Jun 13 08:58:55 2020 +0200

    Fix handling of linux bond interfaces

    At present linux bonds will be ignored when mentioned directly
    in configuration options parsed by the ``BridgePortInterface``
    data structure.

    If a mac address of a physical interface making up the bond is
    listed the code correctly finds the bond name and adds that to
    the bridge.

    Virtual interfaces are ignored when then map is built, linux bonds
    are virtual interfaces.

    This patch fixes the problem by checking physical interfaces for
    bond membership while building the map. If an interface is member
    of a bond add the bond name to the map.

    Previously the bond membership check was only done when looking
    up interface name from mac after building the map.

    Change-Id: I09b17cc039c622373f05423fe9993e0254145f28
    Closes-Bug: #1883244

Changed in charm-ovn-chassis:
status: In Progress → Fix Committed
Changed in charm-ovn-dedicated-chassis:
status: In Progress → Fix Committed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to charm-ovn-dedicated-chassis (master)

Reviewed: https://review.opendev.org/735416
Committed: https://git.openstack.org/cgit/x/charm-ovn-dedicated-chassis/commit/?id=662c34b5643972a67a885a9bf8cae289b7969440
Submitter: Zuul
Branch: master

commit 662c34b5643972a67a885a9bf8cae289b7969440
Author: Frode Nordahl <email address hidden>
Date: Sat Jun 13 09:01:11 2020 +0200

    Fix handling of linux bond interfaces

    At present linux bonds will be ignored when mentioned directly
    in configuration options parsed by the ``BridgePortInterface``
    data structure.

    If a mac address of a physical interface making up the bond is
    listed the code correctly finds the bond name and adds that to
    the bridge.

    Virtual interfaces are ignored when then map is built, linux bonds
    are virtual interfaces.

    This patch fixes the problem by checking physical interfaces for
    bond membership while building the map. If an interface is member
    of a bond add the bond name to the map.

    Previously the bond membership check was only done when looking
    up interface name from mac after building the map.

    Change-Id: I941609236ff2bad62b191d0adf4a36bd2b34a42b
    Closes-Bug: #1883244

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to charm-ovn-chassis (stable/20.05)

Fix proposed to branch: stable/20.05
Review: https://review.opendev.org/735887

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to charm-ovn-dedicated-chassis (stable/20.05)

Fix proposed to branch: stable/20.05
Review: https://review.opendev.org/735888

Frode Nordahl (fnordahl)
Changed in charm-helpers:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to charm-ovn-chassis (stable/20.05)

Reviewed: https://review.opendev.org/735887
Committed: https://git.openstack.org/cgit/x/charm-ovn-chassis/commit/?id=93ec88eca1659e35239744cc53e1837529e705d2
Submitter: Zuul
Branch: stable/20.05

commit 93ec88eca1659e35239744cc53e1837529e705d2
Author: Frode Nordahl <email address hidden>
Date: Sat Jun 13 08:58:55 2020 +0200

    Fix handling of linux bond interfaces

    At present linux bonds will be ignored when mentioned directly
    in configuration options parsed by the ``BridgePortInterface``
    data structure.

    If a mac address of a physical interface making up the bond is
    listed the code correctly finds the bond name and adds that to
    the bridge.

    Virtual interfaces are ignored when then map is built, linux bonds
    are virtual interfaces.

    This patch fixes the problem by checking physical interfaces for
    bond membership while building the map. If an interface is member
    of a bond add the bond name to the map.

    Previously the bond membership check was only done when looking
    up interface name from mac after building the map.

    Change-Id: I09b17cc039c622373f05423fe9993e0254145f28
    Closes-Bug: #1883244

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to charm-ovn-dedicated-chassis (stable/20.05)

Reviewed: https://review.opendev.org/735888
Committed: https://git.openstack.org/cgit/x/charm-ovn-dedicated-chassis/commit/?id=d9e1da1fb168510c42119a9bf8c74fbb310deed0
Submitter: Zuul
Branch: stable/20.05

commit d9e1da1fb168510c42119a9bf8c74fbb310deed0
Author: Frode Nordahl <email address hidden>
Date: Sat Jun 13 09:01:11 2020 +0200

    Fix handling of linux bond interfaces

    At present linux bonds will be ignored when mentioned directly
    in configuration options parsed by the ``BridgePortInterface``
    data structure.

    If a mac address of a physical interface making up the bond is
    listed the code correctly finds the bond name and adds that to
    the bridge.

    Virtual interfaces are ignored when then map is built, linux bonds
    are virtual interfaces.

    This patch fixes the problem by checking physical interfaces for
    bond membership while building the map. If an interface is member
    of a bond add the bond name to the map.

    Previously the bond membership check was only done when looking
    up interface name from mac after building the map.

    Change-Id: I941609236ff2bad62b191d0adf4a36bd2b34a42b
    Closes-Bug: #1883244

Frode Nordahl (fnordahl)
Changed in charm-ovn-chassis:
status: Fix Committed → Fix Released
Changed in charm-ovn-dedicated-chassis:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.