Based on discussion [1], if this becomes a burning issue for some other more realistic use case, we can consider introducing an atomic update of the device id and/or device owner field.
[1] http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-12-15-15.01.log.html ** Changed in: neutron Status: Triaged => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1500365 Title: neutron port API does not support atomicity Status in neutron: Won't Fix Bug description: Neutron port API offers an update method where the user of the API can say "I use this port" by setting the device_owner and device_id fields of the port. However the neutron API does not prevent port allocation race conditions. The API semantic is that a port is used if the device_id and the device_owner fields are set, and not used if they aren't. Now lets have two clients that both want to set the ownership of the port. Both clients first have to check if the port is free or not by checking the value of the device_owner and device_id fields of the port, then they have to set the those fields to express ownership. If the two clients act parallel it is pretty much possible that both clients see that the fields are empty and both issue the port update command. This can leads to race conditions between clients. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1500365/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
