Reviewed: https://review.openstack.org/426339
Committed:
https://git.openstack.org/cgit/openstack/neutron/commit/?id=38de22bf2d4c0879a84db4fbc9fa030f181affc0
Submitter: Jenkins
Branch: master
commit 38de22bf2d4c0879a84db4fbc9fa030f181affc0
Author: Kevin Benton <blak...@gmail.com>
Date: Fri Jan 27 10:35:44 2017 -0800
Always acquire network.id lock in dhcp port update
Looking at the cache before aqcuiring a lock may cause the
agent to mistakenly think the network doesn't exist when it
is actually being wired in parallel.
Always acquiring the network-based semaphore will ensure that
the network isn't currently being setup in another coroutine.
Closes-Bug: #1659919
Change-Id: I99ae71e3c5b1cd91dca3f6c80b04d2ecb79de64f
** Changed in: neutron
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1659919
Title:
dhcp agent race with port update and network create
Status in neutron:
Fix Released
Bug description:
Root cause analysis of http://logs.openstack.org/01/410501/5/gate
/gate-tempest-dsvm-neutron-full-ubuntu-xenial/3f7b603/ race condition:
* shows that port for VM did not go to ACTIVE because DHCP agent didn't
notify server that it setup the DHCP reservation.
* DHCP agent didn't setup the reservation because it didn't have the network
in its cache yet when it received the port update but it had already started
wiring the network in another thread
* the port didn't exist on the server when the network setup thread asked the
server for all ports on the network
So fix is that port_update needs to acquire network lock even if network
doesn't appear to be in cache.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1659919/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
