Comment 4 for bug 1882804

I try to summarize the current approach:

* In case of the port has QoS policy with minimum bandwidth rule and update changes the QoS policy to a different minkbs value:

** neutron calls for placement (see: https://review.opendev.org/741452 ) to fetch the allocation and update the related allocation in placement's db.

** As Gibi wrote above: due to parallel placement allocation updates it is possible that
*** the call fails as the allocation was moved to another RP (server move)
*** the call must be repeated as the allocation was changed (i.e.: vCPU allocation for the same device/consumer)

** The proposal is to add the call for placement outside db transaction, as PORT AFTER_UPDATE callback.

** It is possible that the allocation change is still in progress while other operations related to port update are finished, so a new field "update_status" should be used to show the user the status of port update.

*** "port_update_status" extension should be supported now by qos_plugin.

*** The "update_status" should be "ACTIVE" for fresh new just created port.

*** In case of update where there is no QoS policy affected the "update_status" changes to ACTIVE (effectively no change)

*** In case where port update affects QoS policy with min bw minkbps, in current _validate_update_port_callback (https://opendev.org/openstack/neutron/src/branch/master/neutron/services/qos/qos_plugin.py#L175 ) the "update_status" field changed to PORT_STATUS_BUILD (good question if it is a good status for this case)

*** The "update_status" field can be changed to "ACTIVE" if the AFTER_UPDATE callback succeeds and placement allocation update is ready.