Race condition on processing DVR floating IPs
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Fix Released
|
High
|
Rajeev Grover | ||
Juno |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
A race condition can sometimes occur in l-3 agent when a dvr based floatingip is being deleted from one router and another dvr based floatingip is being configured on another router in the same node. Especially if the floatingip being deleted was the last floatingip on the node. Although fix for Bug # 1373100 [1] eliminated frequent observation of this behavior in upstream tests, it still shows up. Couple of recent examples:
http://
http://
Relevant log messages:
2014-10-14 16:06:15.803 22303 DEBUG neutron.
2014-10-14 16:06:15.838 22303 DEBUG neutron.
Command: ['sudo', '/usr/local/
Exit code: 0
Stdout: '2: rfp-7ed86ca6-b: <BROADCAST,
Stderr: '' execute /opt/stack/
2014-10-14 16:06:15.839 22303 DEBUG neutron.
2014-10-14 16:06:16.221 22303 DEBUG neutron.
Command: ['sudo', '/usr/local/
Exit code: 0
Stdout: ''
Stderr: '' execute /opt/stack/
2014-10-14 16:06:16.222 22303 DEBUG neutron.
2014-10-14 16:06:16.222 22303 DEBUG neutron.
2014-10-14 16:06:16.251 22303 ERROR neutron.
Command: ['sudo', '/usr/local/
Exit code: 1
Stdout: ''
Stderr: 'Cannot find device "rfp-7ed86ca6-b"\n'
Changed in neutron: | |
status: | New → Confirmed |
importance: | Undecided → High |
Changed in neutron: | |
assignee: | nobody → Rajeev Grover (rajeev-grover) |
status: | Confirmed → In Progress |
tags: | added: l3-dvr-backlog |
tags: | added: juno-backport-potential |
Changed in neutron: | |
milestone: | none → kilo-1 |
status: | Fix Committed → Fix Released |
Changed in neutron: | |
milestone: | kilo-1 → 2015.1.0 |
fix in progress: /review. openstack. org/#/c/ 128131/
https:/