Functional test_ipwrapper_get_device_by_ip fails with new kernels

[Assaf Muller]

Trace:
http://paste.openstack.org/show/480710/

The test creates a device via:
sudo ip tuntap add test223ef12 mode tap

Which on my system (Fedora 22) results in a device called:
test223ef12@NONE

And the test fails to compare 'test223ef12' to 'test223ef12@NONE'.

[Assaf Muller (amuller)]

The test failure probably exposed a failure in the production code rather than a test-only failure but I haven't given this too much thought yet.

[Haim Daniel (hdaniel)]

interesting - I've tried running the $cmd on both FC23 && FC22 , which resulted in test223ef12 device being created properly.

[Haim Daniel (hdaniel)]

* Being more helpful*
The systems which I tried this on:

Linux hdaniel-x1.usersys.redhat.com 4.2.5-300.fc23.x86_64 #1 SMP Tue Oct 27 04:29:56 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Linux hd-vm-fc22.usersys.redhat.com 4.2.5-201.fc22.x86_64 #1 SMP Wed Oct 28 20:00:23 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

[John Schwarz (jschwarz)]

@Assaf, please provide the version of 'iproute' and the kernel version you're using.

[Assaf Muller (amuller)]

cat /etc/redhat-release
Fedora release 22 (Twenty Two)

uname -r
4.1.7-200.fc22.x86_64

rpm -qa iproute
iproute-3.16.0-3.fc22.x86_64

[John Schwarz (jschwarz)]

This reproduces easily when using Fedora Core 22 with the kernel version of 4.1.7-200.

The suffix is actually pointing to the other end of some virtual device, so for example adding a veth pair will yield 'veth0@veth1', signifying that veth0 is connected to veth1. "@NONE" is used when the device is not connected anywhere.

In any case, all code that parses 'ip link' or 'ip addr' should be fixed. Specifically, get_device_by_ip, ip monitor and possibly l3 ha are all affected by this.

Note that in later versions of the kernel, this is not happening for devices with no end point (that is, 'veth0@veth1' will still appear but 'mytap@NONE' will not).

[John Schwarz (jschwarz)]

The fix, btw, is to have 'get_device_by_ip' and the likes return the device name without the suffix, since using the device name with the suffix in 'ip addr' commands (such as adding IPs) fails if the suffix exists.

[John Schwarz (jschwarz)]

It would seem that ip monitor and keepalived are not affected by this: 'ip monitor' returns output without the '@...' suffix, and keepalived only takes the first 13 characters anyway.

I'm pondering the idea of adding a safeguard to the ip monitor's code, just in case.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/254801

[OpenStack Infra (hudson-openstack)]

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

commit 8ddeb4be9e32e5cefab8324d0cbf9cecead1f808
Author: John Schwarz <email address hidden>
Date: Tue Dec 8 16:17:46 2015 +0200

    Ignore possible suffix in iproute commands.

    Closes-Bug: #1522199
    Change-Id: I14815abd9345edb079e3331cbe2465ad22a0d4c3

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/liberty
Review: https://review.openstack.org/257946

[Ihar Hrachyshka (ihar-hrachyshka)]

FYI: kilo is not affected, since the method does not return device_name there in the first place.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/257946
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=70e7d3ebfdb37d624cff10dbdcd17af2ff3ebd7a
Submitter: Jenkins
Branch: stable/liberty

commit 70e7d3ebfdb37d624cff10dbdcd17af2ff3ebd7a
Author: John Schwarz <email address hidden>
Date: Tue Dec 8 16:17:46 2015 +0200

    Ignore possible suffix in iproute commands.

    Closes-Bug: #1522199
    Change-Id: I14815abd9345edb079e3331cbe2465ad22a0d4c3
    (cherry picked from commit 8ddeb4be9e32e5cefab8324d0cbf9cecead1f808)
    Conflicts:
     neutron/agent/linux/ip_monitor.py

[Thierry Carrez (ttx)]

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

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/neutron 7.0.2 release.