Public bug reported: The port.resource_request field is admin only. Nova depends on the value of this field to do a proper scheduling and resource allocation / deallocation for such ports as well as to update the port.binding:profile.allocation field with the resource providers the requested resources are fulfilled from. However in some cases[1][2][3] nova does not use a neutron admin client / elevated context to read the port. In this case neutron returns None for the port.resource_request field and nova thinks that the port has no resource request.
This leads to the following bad behavior if the operation is called by a non admin user: * in case of live migration the resource allocation is correct but the port.binding:profile.allocation values still point to the resource providers on the old compute. This could leads to port binding failure * in case of interface detach operation the port is detached successfully but the resource allocation for the port is leaked in placement until the whole server is deleted. * in case of interface attach in a system where old (pre Xena) computes are present the interface attach is accepted even if the old compute cannot handle the attach of such port properly. I will push a set of reproduction tests soon. [1] https://github.com/openstack/nova/blob/e07bb310b674fb471a92edf3258e564f05534595/nova/network/neutron.py#L1049 [2] https://github.com/openstack/nova/blob/e07bb310b674fb471a92edf3258e564f05534595/nova/network/neutron.py#L1727 [3] https://github.com/openstack/nova/blob/e07bb310b674fb471a92edf3258e564f05534595/nova/compute/api.py#L5144 ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1945310 Title: Live migration and interface detach with non admin user is broken for Servers with port having resource request Status in OpenStack Compute (nova): New Bug description: The port.resource_request field is admin only. Nova depends on the value of this field to do a proper scheduling and resource allocation / deallocation for such ports as well as to update the port.binding:profile.allocation field with the resource providers the requested resources are fulfilled from. However in some cases[1][2][3] nova does not use a neutron admin client / elevated context to read the port. In this case neutron returns None for the port.resource_request field and nova thinks that the port has no resource request. This leads to the following bad behavior if the operation is called by a non admin user: * in case of live migration the resource allocation is correct but the port.binding:profile.allocation values still point to the resource providers on the old compute. This could leads to port binding failure * in case of interface detach operation the port is detached successfully but the resource allocation for the port is leaked in placement until the whole server is deleted. * in case of interface attach in a system where old (pre Xena) computes are present the interface attach is accepted even if the old compute cannot handle the attach of such port properly. I will push a set of reproduction tests soon. [1] https://github.com/openstack/nova/blob/e07bb310b674fb471a92edf3258e564f05534595/nova/network/neutron.py#L1049 [2] https://github.com/openstack/nova/blob/e07bb310b674fb471a92edf3258e564f05534595/nova/network/neutron.py#L1727 [3] https://github.com/openstack/nova/blob/e07bb310b674fb471a92edf3258e564f05534595/nova/compute/api.py#L5144 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1945310/+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
