[Yahoo-eng-team] [Bug 1500365] Re: neutron port API does not support atomicity

2015-12-15 Thread Armando Migliaccio
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 : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp


[Yahoo-eng-team] [Bug 1500365] Re: neutron port API does not support atomicity

2015-10-09 Thread Armando Migliaccio
We are aware of some of the limitations of the existing API. This will
definitely require more attention across the board. Marking RFE, to
raise the profile of this bug and seek input from members of the drivers
team.

** Tags added: rfe

** Changed in: neutron
   Status: Opinion => Triaged

** Changed in: neutron
   Status: Triaged => Confirmed

-- 
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:
  Confirmed

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 : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp


[Yahoo-eng-team] [Bug 1500365] Re: neutron port API does not support atomicity

2015-09-28 Thread Eugene Nikanorov
>From API perspective, there is no restriction on port ownership within one 
>tenant. 
If tenant wants to change the ownership - it can do that. Also, there is no 
problems with atomicity, because API calls act quite atomically. 
What you are looking for is transactional semantics where such client problem 
could be resolved, but I don't think neutron is going to provide such ability 
any time soon, and also I don't think it is on the map.

** Changed in: neutron
   Status: New => Opinion

-- 
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:
  Opinion

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 : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp