`brctl setageing $bridge 0` fails on Ubuntu 16.04 4.4.0-21-generic

[Lee Yarwood]

This leads to the following error when attempting to plug OVS VIFs:

Feb 16 09:31:57 host1.example.com nova-compute[25485]: Stderr: u'set ageing time failed: Numerical result out of range\n'
Feb 16 09:31:57 host1.example.com nova-compute[25485]: ERROR os_vif Traceback (most recent call last):
Feb 16 09:31:57 host1.example.com nova-compute[25485]: ERROR os_vif File "/usr/local/lib/python2.7/dist-packages/os_vif/__init__.py", line 77, in plug
Feb 16 09:31:57 host1.example.com nova-compute[25485]: ERROR os_vif plugin.plug(vif, instance_info)
Feb 16 09:31:57 host1.example.com nova-compute[25485]: ERROR os_vif File "/usr/local/lib/python2.7/dist-packages/vif_plug_ovs/ovs.py", line 209, in plug
Feb 16 09:31:57 host1.example.com nova-compute[25485]: ERROR os_vif self._plug_bridge(vif, instance_info)
Feb 16 09:31:57 host1.example.com nova-compute[25485]: ERROR os_vif File "/usr/local/lib/python2.7/dist-packages/vif_plug_ovs/ovs.py", line 161, in _plug_bridge
Feb 16 09:31:57 host1.example.com nova-compute[25485]: ERROR os_vif linux_net.ensure_bridge(vif.bridge_name)
Feb 16 09:31:57 host1.example.com nova-compute[25485]: ERROR os_vif File "/usr/local/lib/python2.7/dist-packages/oslo_privsep/priv_context.py", line 207, in _wrap
Feb 16 09:31:57 host1.example.com nova-compute[25485]: ERROR os_vif return self.channel.remote_call(name, args, kwargs)
Feb 16 09:31:57 host1.example.com nova-compute[25485]: ERROR os_vif File "/usr/local/lib/python2.7/dist-packages/oslo_privsep/daemon.py", line 202, in remote_call
Feb 16 09:31:57 host1.example.com nova-compute[25485]: ERROR os_vif raise exc_type(*result[2])
Feb 16 09:31:57 host1.example.com nova-compute[25485]: ERROR os_vif ProcessExecutionError: Unexpected error while running command.
Feb 16 09:31:57 host1.example.com nova-compute[25485]: ERROR os_vif Command: brctl setageing qbrb182f36d-14 0
Feb 16 09:31:57 host1.example.com nova-compute[25485]: ERROR os_vif Exit code: 1
Feb 16 09:31:57 host1.example.com nova-compute[25485]: ERROR os_vif Stdout: u''
Feb 16 09:31:57 host1.example.com nova-compute[25485]: ERROR os_vif Stderr: u'set ageing time failed: Numerical result out of range\n'

I'm able to reproduce this manually with:

# brctl addbr test
# brctl setageing test 0
set ageing time failed: Numerical result out of range

# dpkg --list | grep bridge-utils
ii bridge-utils 1.5-9ubuntu1 amd64 Utilities for configuring the Linux Ethernet bridge
# uname -a
Linux host1.example.com 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

I've glanced over the bridge-utils code but can't see anything obvious that could cause this, the actual error appears to be coming up from the kernel.

[sean mooney (sean-k-mooney)]

setting the bridge aging to 0 was introduced in
https://github.com/openstack/os-vif/commit/fa4ff64b86e6e1b6399f7250eadbee9775c22d32
to resolve https://bugs.launchpad.net/nova/+bug/1715317
and partially addresses https://bugs.launchpad.net/neutron/+bug/1414559

so bassicaly the intent was to prevent mac adresses form expiring on the linux
bridges used for hybrid plug. it is not strictly required but should help prevent
packet loss during a live migration.

using the same version of bridge-utils but with a newer version of the ubuntu 16.04 lts kernel i cannot reproduce manually.

ubuntu@ubuntu:~$ uname -a
Linux ubuntu 4.4.0-112-generic #135-Ubuntu SMP Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

my guess is that the kernel ioctl interfaces changed slightly between 4.4.0-21 and -112

setting the againg to 0 was intended to disable aging but perhaps that was not supported previously.

is this showing up in the ci or just localy. its not the end of the world if this call fails so we whould catch the exception and ignore/log it at debug level if it fails. there is no reason to fail plugging the vif if mac agging is not disabled.

[Lee Yarwood (lyarwood)]

Marking the bug as invalid, I somehow managed to build 16.04 images using virt-builder with the GA kernel instead of the latest from updates. I can't reproduce this issue with the same -112 kernel as used by Sean in c#1, apologies for the noise and thanks to Sean for taking the time to look at this.