← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1534447] Re: ip allocation can be taken after dup check before commit

 

Reviewed:  https://review.openstack.org/267930
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=f67fc3cb08ce4f0e6fc685801a243fe68503578e
Submitter: Jenkins
Branch:    master

commit f67fc3cb08ce4f0e6fc685801a243fe68503578e
Author: Kevin Benton <blak111@xxxxxxxxx>
Date:   Thu Jan 14 20:23:32 2016 -0800

    Retry port create/update on duplicate db records
    
    Even though we have a duplicate IP check before creating an IP
    allocation, there is a window between when that check is completed
    and when the record is committed to the database. During this window,
    another thread or server may use the same IP address, which will result
    in the database commit failing with a DBDuplicateEntry exception.
    
    This patch adds a decorator to convert the exception into a
    RetryRequest, which will be caught at the API layer to start the
    operation over, at which point the normal duplicate check will find
    the IP and return the correct error to the user.
    
    This was done instead of trying to convert the DBDuplicate to the
    correct exception since it's on commit and there are possibly many
    different sources of the duplicate record beyond the IP allocation
    (depending on what mechanism drivers did during pre-commit, etc).
    By retrying the request, we ensure that the prechecks run again that
    will raise the appropriate exception.
    
    Change-Id: I37a964497bf60a61bc49bdeec94a008f167c384f
    Closes-Bug: #1534447


** Changed in: neutron
       Status: In Progress => Fix Released

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

Title:
  ip allocation can be taken after dup check before commit

Status in neutron:
  Fix Released

Bug description:
  A concurrent thread/server can use an IP allocation before the port
  creation that attempts to insert it on the local server gets a chance
  to commit its transaction to the database. So even though we have a
  dup check, it may return that the IP is not in use right before
  something else steals it.

  http://logs.openstack.org/38/257938/9/gate/gate-neutron-dsvm-
  api/d98d247/logs/screen-q-svc.txt.gz?level=ERROR

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


References