Comment 29 for bug 1491317

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to neutron (master)

Reviewed: https://review.openstack.org/574673
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=4088461ed6cdbc3b1a6896cb03596dd4c3a64d05
Submitter: Zuul
Branch: master

commit 4088461ed6cdbc3b1a6896cb03596dd4c3a64d05
Author: ZhaoBo <email address hidden>
Date: Tue Jul 3 22:12:47 2018 +0800

    [server side] Fix race issue for port forwarding plugin

    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