yahoo-eng-team team mailing list archive

[Luis Tomas Bolivar <1657441@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

This is not required by business logic as pointed out in the commit
message of https://review.openstack.org/#/c/368289/, and in some
cases can lead to race problems.

There may be other proyects using neutron TrunkPorts, such as kuryr,
that can trigger the port/subport creation, therefore wanting to use
the device_owner to specify that kuryr-service is the one managing
those subports.

To give an example of the possible race, as the trunk_add_subport
internally calls update_port to set the device owner, it may happen that
a call from kuryr that wants to attach a subport to a port, and then set
the device_owner to kuryr, end up with the wrong device_owner as, 
even though the calls are triggered in this order:
1.- trunk_add_subport (internally calls update_port)
2.- update_port

The update_port is executed between trunk_add_subport and the internal call to
update_port, resulting in device_owner being set to trunk:subport, instead of
kuryr.

Possible solutions are:
- Revert the commit https://review.openstack.org/#/c/368289/. We have already 
have some discussion about this in the patch https://review.openstack.org/#/c/419028/
- Make the set device_owner optional based on the value of TRUNK_SUBPORT_OWNER
- Define what should be the scope of device_owner to clarify how this attribute
should be used within/outside neutron

** Affects: neutron
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1657441

Title:
  Remove the set device_owner when attaching subports

Status in neutron:
  New

Bug description:
  This is not required by business logic as pointed out in the commit
  message of https://review.openstack.org/#/c/368289/, and in some
  cases can lead to race problems.

  There may be other proyects using neutron TrunkPorts, such as kuryr,
  that can trigger the port/subport creation, therefore wanting to use
  the device_owner to specify that kuryr-service is the one managing
  those subports.

  To give an example of the possible race, as the trunk_add_subport
  internally calls update_port to set the device owner, it may happen that
  a call from kuryr that wants to attach a subport to a port, and then set
  the device_owner to kuryr, end up with the wrong device_owner as, 
  even though the calls are triggered in this order:
  1.- trunk_add_subport (internally calls update_port)
  2.- update_port

  The update_port is executed between trunk_add_subport and the internal call to
  update_port, resulting in device_owner being set to trunk:subport, instead of
  kuryr.

  Possible solutions are:
  - Revert the commit https://review.openstack.org/#/c/368289/. We have already 
  have some discussion about this in the patch https://review.openstack.org/#/c/419028/
  - Make the set device_owner optional based on the value of TRUNK_SUBPORT_OWNER
  - Define what should be the scope of device_owner to clarify how this attribute
  should be used within/outside neutron

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1657441/+subscriptions