Comment 1 for bug 1832307

So I looked at:

http://logs.openstack.org/14/639814/10/check/neutron-functional-python27/82513e0/testr_results.html.gz

And it looks like the last address getting added never shows up in the temp file:

Defined IP addresses:
[{'event': 'added', 'name': 'int_3375df43-ef', 'cidr': '192.168.250.1/24'},
{'event': 'added', 'name': 'int_35f82664-c5', 'cidr': '192.168.250.2/24'},
{'event': 'added', 'name': 'int_b45a7b12-d9', 'cidr': '192.168.250.3/24'},
{'event': 'added', 'name': 'int_fbd453a0-32', 'cidr': '192.168.250.10/24'},
{'event': 'removed', 'name': 'int_fbd453a0-32', 'cidr': '192.168.250.10/24'},
{'event': 'added', 'name': 'int_ac1ff1e9-ab', 'cidr': '2001:db8::1/64'},
{'event': 'added', 'name': 'int_ac1ff1e9-ab', 'cidr': '2001:db8::2/64'}]

IP addresses registered:
{"broadcast": "192.168.250.255", "dadfailed": false, "name": "int_3375df43-ef", "tentative": false, "scope": "global", "cidr": "192.168.250.1/24", "dynamic": false, "event": "added"}
{"broadcast": "192.168.250.255", "dadfailed": false, "name": "int_35f82664-c5", "tentative": false, "scope": "global", "cidr": "192.168.250.2/24", "dynamic": false, "event": "added"}
{"broadcast": "192.168.250.255", "dadfailed": false, "name": "int_b45a7b12-d9", "tentative": false, "scope": "global", "cidr": "192.168.250.3/24", "dynamic": false, "event": "added"}
{"broadcast": "192.168.250.255", "dadfailed": false, "name": "int_fbd453a0-32", "tentative": false, "scope": "global", "cidr": "192.168.250.10/24", "dynamic": false, "event": "added"}
{"broadcast": null, "dadfailed": false, "name": "int_ac1ff1e9-ab", "tentative": false, "scope": "global", "cidr": "2001:db8::1/64", "dynamic": false, "event": "added"}
...

There's other addresses on other interfaces in the logs after that, but not '2001:db8::2/64'

Running a test in a namespace, one window running 'ip -o monitor address' and another running /sbin/ip commands as above showed all the addresses being output.

One of the other traces showed the 250.10 IP never getting added, but getting removed, but the IPv6 ones were fine.

So we'll need to run the code in question to try and debug further, or see what kernel version this was running if there is a clue there.