yahoo-eng-team team mailing list archive

[Roman Podoliaka <rpodolyaka@xxxxxxxxxxxx>]

Public bug reported:

tl;dr

In a few versions of oslo.db (maybe when we release 1.0.0?), every
project using oslo.db should inspect their code and remove usages of
'raw' DB exceptions like IntegrityError/OperationalError/etc from except
clauses and replace them with the corresponding custom exceptions from
oslo.db (at least a base one - DBError).

Full version

A recent commit to oslo.db changed the way the 'raw' DB exceptions are
wrapped (e.g. IntegrityError, OperationalError, etc). Previously, we
used decorators on Session methods and wrapped those exceptions with
oslo.db custom ones. This is mostly useful for handling them later (e.g.
to retry DB API methods on deadlocks).

The problem with Session decorators was that it wasn't possible to catch
and wrap all possible exceptions. E.g. SA Core exceptions and exceptions
raised in Query.all() calls were ignored. Now we are using a low level
SQLAlchemy event to catch all possible DB exceptions. This means that if
consuming projects had workarounds for those cases and expected 'raw'
exceptions instead of oslo.db ones, they would be broken. That's why we
*temporarily* added both 'raw' exceptions and new ones to expect clauses
in consuming projects code when they were ported to using of oslo.db to
make the transition smooth and allow them to work with different oslo.db
versions.

On the positive side, we now have a solution for problems like
https://bugs.launchpad.net/nova/+bug/1283987 when exceptions in Query
methods calls weren't handled properly.

In a few releases of oslo.db we can safely remove 'raw' DB exceptions
like IntegrityError/OperationalError/etc from projects code and except
only oslo.db specific ones like
DBDuplicateError/DBReferenceError/DBDeadLockError/etc (at least, we wrap
all the DB exceptions with our base exception DBError, if we haven't
found a better match).

oslo.db exceptions and their description:
https://github.com/openstack/oslo.db/blob/master/oslo/db/exception.py

** Affects: nova
     Importance: Undecided
         Status: New


** Tags: db

** Description changed:

  tl;dr
  
- In a few versions of oslo.db (maybe when we release 1.0.0), every
+ In a few versions of oslo.db (maybe when we release 1.0.0?), every
  project using oslo.db should inspect their code and remove usages of
  'raw' DB exceptions like IntegrityError/OperationalError/etc from except
  clauses and replace them with the corresponding custom exceptions from
  oslo.db (at least a base one - DBError).
  
- 
  Full version
  
- 
- A recent commit to oslo.db changed the way the 'raw' DB exceptions are wrapped (e.g. IntegrityError, OperationalError, etc). Previously, we used decorators on Session methods and wrapped those exceptions with oslo.db custom ones. This is mostly useful for handling them later (e.g. to retry DB API methods on deadlocks).
+ A recent commit to oslo.db changed the way the 'raw' DB exceptions are
+ wrapped (e.g. IntegrityError, OperationalError, etc). Previously, we
+ used decorators on Session methods and wrapped those exceptions with
+ oslo.db custom ones. This is mostly useful for handling them later (e.g.
+ to retry DB API methods on deadlocks).
  
  The problem with Session decorators was that it wasn't possible to catch
  and wrap all possible exceptions. E.g. SA Core exceptions and exceptions
  raised in Query.all() calls were ignored. Now we are using a low level
  SQLAlchemy event to catch all possible DB exceptions. This means that if
  consuming projects had workarounds for those cases and expected 'raw'
  exceptions instead of oslo.db ones, they would be broken. That's why we
  *temporarily* added both 'raw' exceptions and new ones to expect clauses
  in consuming projects code when they were ported to using of oslo.db. On
  the positive side, we now have a solution for problems like
  https://bugs.launchpad.net/nova/+bug/1283987 when exceptions in Query
  methods calls weren't handled properly.
  
  In a few releases of oslo.db we can safely remove 'raw' DB exceptions
  like IntegrityError/OperationalError/etc from projects code and except
  only oslo.db specific ones like
  DBDuplicateError/DBReferenceError/DBDeadLockError/etc (at least, we wrap
  all the DB exceptions with our base exception DBError, if we haven't
  found a better match).
  
  oslo.db exceptions and their description:
  https://github.com/openstack/oslo.db/blob/master/oslo/db/exception.py

** Tags added: db

** Description changed:

  tl;dr
  
  In a few versions of oslo.db (maybe when we release 1.0.0?), every
  project using oslo.db should inspect their code and remove usages of
  'raw' DB exceptions like IntegrityError/OperationalError/etc from except
  clauses and replace them with the corresponding custom exceptions from
  oslo.db (at least a base one - DBError).
  
  Full version
  
  A recent commit to oslo.db changed the way the 'raw' DB exceptions are
  wrapped (e.g. IntegrityError, OperationalError, etc). Previously, we
  used decorators on Session methods and wrapped those exceptions with
  oslo.db custom ones. This is mostly useful for handling them later (e.g.
  to retry DB API methods on deadlocks).
  
  The problem with Session decorators was that it wasn't possible to catch
  and wrap all possible exceptions. E.g. SA Core exceptions and exceptions
  raised in Query.all() calls were ignored. Now we are using a low level
  SQLAlchemy event to catch all possible DB exceptions. This means that if
  consuming projects had workarounds for those cases and expected 'raw'
  exceptions instead of oslo.db ones, they would be broken. That's why we
  *temporarily* added both 'raw' exceptions and new ones to expect clauses
- in consuming projects code when they were ported to using of oslo.db. On
- the positive side, we now have a solution for problems like
+ in consuming projects code when they were ported to using of oslo.db to
+ make the transition smooth and allow them to work with different oslo.db
+ versions.
+ 
+ On the positive side, we now have a solution for problems like
  https://bugs.launchpad.net/nova/+bug/1283987 when exceptions in Query
  methods calls weren't handled properly.
  
  In a few releases of oslo.db we can safely remove 'raw' DB exceptions
  like IntegrityError/OperationalError/etc from projects code and except
  only oslo.db specific ones like
  DBDuplicateError/DBReferenceError/DBDeadLockError/etc (at least, we wrap
  all the DB exceptions with our base exception DBError, if we haven't
  found a better match).
  
  oslo.db exceptions and their description:
  https://github.com/openstack/oslo.db/blob/master/oslo/db/exception.py

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1364986

Title:
  oslo.db now wraps all DB exceptions

Status in OpenStack Compute (Nova):
  New

Bug description:
  tl;dr

  In a few versions of oslo.db (maybe when we release 1.0.0?), every
  project using oslo.db should inspect their code and remove usages of
  'raw' DB exceptions like IntegrityError/OperationalError/etc from
  except clauses and replace them with the corresponding custom
  exceptions from oslo.db (at least a base one - DBError).

  Full version

  A recent commit to oslo.db changed the way the 'raw' DB exceptions are
  wrapped (e.g. IntegrityError, OperationalError, etc). Previously, we
  used decorators on Session methods and wrapped those exceptions with
  oslo.db custom ones. This is mostly useful for handling them later
  (e.g. to retry DB API methods on deadlocks).

  The problem with Session decorators was that it wasn't possible to
  catch and wrap all possible exceptions. E.g. SA Core exceptions and
  exceptions raised in Query.all() calls were ignored. Now we are using
  a low level SQLAlchemy event to catch all possible DB exceptions. This
  means that if consuming projects had workarounds for those cases and
  expected 'raw' exceptions instead of oslo.db ones, they would be
  broken. That's why we *temporarily* added both 'raw' exceptions and
  new ones to expect clauses in consuming projects code when they were
  ported to using of oslo.db to make the transition smooth and allow
  them to work with different oslo.db versions.

  On the positive side, we now have a solution for problems like
  https://bugs.launchpad.net/nova/+bug/1283987 when exceptions in Query
  methods calls weren't handled properly.

  In a few releases of oslo.db we can safely remove 'raw' DB exceptions
  like IntegrityError/OperationalError/etc from projects code and except
  only oslo.db specific ones like
  DBDuplicateError/DBReferenceError/DBDeadLockError/etc (at least, we
  wrap all the DB exceptions with our base exception DBError, if we
  haven't found a better match).

  oslo.db exceptions and their description:
  https://github.com/openstack/oslo.db/blob/master/oslo/db/exception.py

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