This patch fixes the race condition with update/delete neutron
serveral resources, such as port forwarding conflict with
floatingip and port forwarding conflict with port.
Also this approach need the revision function, so need to fix in port
forwarding model to aware relationship revision update.
As the port forwarding resource associated with 2 resources,
one is floatingip, the other is neutron internal port.
So floatingip update/delete maybe in a conflict situation with
port forwarding creation. But for port, we just lack the logic to
process port forwarding during update port's fixed_ip and delete
port.
So the approach here is adding logic to let l3 plugin and port
forwarding plugin know each other when both sides may process the same
floatingip resource. Based on the existing revision_number feature,
if one side fail as db staleError, the api layer will retry the whole
operation for this resource, so there must be a failure on one side in
this case. This patch just adds the association logic for l3 plugin and
port forwarding plugin, also adds a event receiver for port update/delete.
Then the behavior about the port forwarding associated resources would
be:
* For fip resource, I introduce one function in that patch.
_check_floatingip_request
So during floatingip update/delete, the function will process
fip and check by rpc callback from l3_plugin, if port forwarding plugin
also creates a port forwarding with the same fip at this moment. The
success side would be the one who update the fip_db first, the other side
would be failure after db retry.
* For port resource, during update port fixed_ip or delete port, we will
delete the associated port forwarding resources for free the
fip:external_port socket.
Partially-Implements: blueprint port-forwarding
Change-Id: I637ebcb33b91d899a077bded5ca10097a830a847
Partial-Bug: #1491317
4088461ed6