yahoo-eng-team team mailing list archive

[OpenStack Infra <1590316@xxxxxxxxxxxxxxxxxx>]

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

commit 143b19c8d5e6805c4ce0abe78748c0add42a2072
Author: Kevin Benton <kevin@xxxxxxxxxx>
Date:   Tue Jun 7 15:27:48 2016 -0700

    Separate exception class for retriables in callbacks
    
    There are various places where we emit a callback to allow
    subscribers to do validation or additional bookkeeping during
    the various life-cycle events of objects. However, a subscriber
    can encounter a DB Deadlock, StaleDataError or other retriable
    error that just needs the transaction to be restarted. In the
    rest of the Neutron code these exceptions bubble up to the API
    layer where the whole request is restarted. However, the exception
    catching for the callbacks in various places was preventing these
    errors from being retried because they were lost in conversion.
    
    This patch has the callback manager convert retriable exceptions
    into RetryRequest exceptions that will not be caught by handlers
    of CallbackError so by default it will bubble up to the API layer
    and be retried. 'notify' callers can avoid this behavior by
    additionally catching RetryRequest.
    
    Closes-Bug: #1590316
    Change-Id: I6732c60f89de4318b5f56327c5bc966bd250baae


** 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/1590316

Title:
  exception handling of callback failures doesn't take into account
  retriable errors

Status in neutron:
  Fix Released

Bug description:
  Subscribers to callback events can perform DB operations that may
  encounter deadlocks or other DB errors that should be retried after
  restarting the entire transaction. However, in the cases where we
  catch exceptions.CallbackFailure and then raise a different exception,
  the DB retry wrapper cannot recognize that it is retriable failure and
  will make it fatal for the request. This can lead to a user getting a
  SubnetInUse or something similar because of something completely
  unrelated to the actual validation.

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