summaryrefslogtreecommitdiff
path: root/oslo_db/api.py
Commit message (Collapse)AuthorAgeFilesLines
* Drop use of sixStephen Finucane2020-02-251-2/+2
| | | | | | | No need for this in a Python 3-only world. Change-Id: I8923f2b87c1bd114b8c55210100c7485a0de8f28 Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
* Improve exponential backoff for wrap_db_retryYikun Jiang2018-04-131-7/+34
| | | | | | | | | | | | | | | | | | | | | The @oslo_db.api.wrap_db_retry is used for db.api methods retrying. If db_error raised, the decorator help us to call the api methods again after a few seconds(accurately, is 2**retry_times seconds). If the db_error is deadlock error, the old wrap_db_retry is not so suitable anymore. As we know, some deadlocks cause because we call some methods(transactions) concurrently. If we only retry after stable 2**retry_times seconds, we will recall the method concurrently again. In order to minimize the chance of regenerating a deadlock and reduce the average sleep time, we propose to add some random jitter to the delay period by default when the deadlock error is detected. Change-Id: I206745708570f1f292529ff58eee9b83fc09a9f2 Closes-bug: #1737869
* Remove kwarg retry_on_request in wrap_db_retrychenghuiyu2017-10-271-4/+1
| | | | | | | | As Retry on request is always enabled, so the kwarg retry_on_request is deprecated for removal. Change-Id: I9c918828ce9f7075a4e33a6fbadd9613c81fa2eb Closes-Bug: #1714440
* Remove log translationschenlx2017-03-301-2/+1
| | | | | | | | | | | | | | Log messages are no longer being translated. This removes all use of the _LE, _LI, and _LW translation markers to simplify logging and to avoid confusion with new contributions. See: http://lists.openstack.org/pipermail/openstack-i18n/2016-November/002574.html http://lists.openstack.org/pipermail/openstack-dev/2017-March/113365.html Closes-Bug: #1674577 Change-Id: I7553ae7c222f61b6796b72ac4a2b744d3e08fee6
* api: use sane default in wrap_db_retry()Julien Danjou2016-06-291-12/+10
| | | | | | | | | | The current defaults do not make much sense: having max_retries set to 0 completely avoid any retry, which is the whole point of that wrapper. This patch moves the correct default values from the DBAPI object to the wrap_db_retry() function itself. Change-Id: I89c2bd09e69b8b77b716573eb8b889c01f9d0f54
* api: do not log a traceback if error is not expectedJulien Danjou2016-06-011-2/+4
| | | | | | | | | | | | | | | | | | | | | Currently, when using the retry decorator on a function that raises an error on the last retry, oslo.db always log the following: ERROR oslo_db.api [-] DB exceeded retry limit. ERROR oslo_db.api Traceback (most recent call last): ERROR oslo_db.api File "/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 138, in wrapper ERROR oslo_db.api return f(*args, **kwargs) ERROR oslo_db.api File "/opt/stack/gnocchi/gnocchi/indexer/sqlalchemy.py", line 686, in list_resources ERROR oslo_db.api raise indexer.InvalidPagination("Invalid sort keys") ERROR oslo_db.api InvalidPagination: Invalid pagination: `Invalid sort keys' Which is wrong, since in this case the `InvalidPagination' is totally unrelated to the retry code. This patch fixes that by only calling LOG.exception if the last try is really about an expected retry condition. Change-Id: Iacc6d3aeac41ddfff76f081428678e2e0688055a Closes-Bug: #1587637
* api: always enable retry_on_requestJulien Danjou2016-05-171-5/+5
| | | | | | | | | | | | | | The current behavior makes by default retry_on_request does not work, which is confusing. Nothing except the developer can raise a RetryRequest, so there can not be any misunderstanding. Having to both enable the switch *and* raise RetryRequest makes it more complicated than it needs to be. This patch simplifies the API by deprecating retry_on_request and retry_on_request() decorator, enabling the exception everywhere wrap_db_retry() is used. Change-Id: I3c53b5c8ba99f460153256fb2e1e6ef01b67f41b
* Clarify the types for retry_interval args of wrap_db_retryHenry Gessau2016-02-181-3/+4
| | | | | | | | | The retry_interval and max_retry_interval can be floats, and inc_retry_interval is a bool. This change has no functional impact. Change-Id: I752c1dd7fe7e2a479b06ab96ad85be4e4a6f5b45
* Don't log non-db error in retry wrapperMatt Riedemann2016-01-131-5/+0
| | | | | | | | | | | | | | | | | | | | | | 838e314a21fef9ca6cf99140b2400e0d3b68b109 changed the retry wrapper code to not log exception traces for expected errors, like when retrying on a DBDeadlock. It did, however, log an unexpected exception but was not checking the type, like in the case of a nova OverQuota exception. Since _is_execption_expected already logs at debug level an expected DB error, like DBDeadlock, during a retry loop, we don't need to log it again. And if the exception is unexpected, like OverQuota from nova, then we shouldn't trace that exception in the retry loop before reraising but instead just let the caller handle it. Adds a unit test to make sure that nothing is logged in the unexpected exception case during the retry loop. Co-Authored-By: Sean Dague <sean@dague.net> Change-Id: Ic3e45029378dc96ce01398d9b55f51e20ef08189 Closes-Bug: #1532880
* Don't trace DB errors when we're retryingMatt Riedemann2015-12-081-1/+6
| | | | | | | | | | | | | | | | | | | | If we know we're retrying on DB failures, let's be smarter and not trace an exception at ERROR level while looping, since this clutters up the logs and causes confusion when trying to track down failures. DBDeadlock errors show up quite a bit in q-svc and n-api logs in gate runs but when you check logstash for those, they are primarily in jobs that are successful, so the trace is on the first try in the loop and then we pass on the second try - but the trace itself is confusing while debugging gate failures. So let's just be smarter and log at debug level between retries, and if we hit an unexpected exception, log that error (as before), and raise it up to the caller. Closes-Bug: #1523990 Change-Id: I15b4a9b5c7ec9bfede9ec9989de02c1da46eac81
* Add debug logging for DB retry attempt.Eugene Nikanorov2015-10-121-0/+3
| | | | | | | | That should help to debug DB contentions. Right now it's not clear from the logs if or how often reconnects are triggered. Change-Id: I8c9c95c262e69d9aa97294abe7fbfb31b1b18c5d
* Allow additional exceptions in wrap_db_retryKevin Benton2015-06-251-18/+30
| | | | | | | | | | | | There are cases where we want to catch and retry some additional exceptions and treat them as RetryRequests depending on method that is being excecuted (e.g. StaleDataError or ObjectDeletedError). This patch changes the wrap_db_retry decorator to take an extra parameter that is a list of additional exception classes that will be caught and treated as a RetryRequest. Change-Id: I6c61b1d2f0331cac31dfde0afa523e44d470b83f
* Avoid excessing logging of RetryRequest exceptionEugene Nikanorov2015-03-171-1/+5
| | | | | | | | | Such exception indicates of error condition only if retries are exceeded. In other cases error-level logs pollute the log file and complicate log analysis. Change-Id: I318867043a68a6499851631593859a0fffac6038 Closes-Bug: #1433001
* Make DBAPI class work with mocks correctly1.5.0Roman Podoliaka2015-02-251-7/+8
| | | | | | | | | | | | | | | | | | | Currently, DBAPI __getattr__() implementation will *always* implicitly wrap all mocked methods of a target class/module using wrap_db_retry(), as retry_on_* attributes will always exist and be true for mock instances. Not only this leads to a situation, when we would retry methods, we were not going to retry, but this also fails with AttributeError on functools.wraps() call, breaking valid unit tests in projects. DBAPI is changed in a way, so that it does dict look ups instead of fetching instance attributes to ensure mocked methods are handled correctly and aren't wrapped when they shouldn't be wrapped. Related issue: http://stackoverflow.com/questions/22204660/python-mock-wrapsf-problems Change-Id: I36550ffa88056c53a431d64e61e84fbb44bbf68d
* Add retry decorator allowing to retry DB operations on requestEugene Nikanorov2015-01-301-4/+24
| | | | | | | | | Improve retrying decorator such that wrapped code could request retry attempt in the arbitrary conditions by raising RetryRequest exception. Wrapped code should provide inner exception that is raised when amount of retries are exceeded. Change-Id: I596fea8dc798a11fcdfdd69208af3313f41d755b
* Merge "Retry query if db deadlock error is received"Jenkins2015-01-271-13/+33
|\
| * Retry query if db deadlock error is receivedrossella2015-01-141-13/+33
| | | | | | | | | | | | | | | | | | Add a decorator retry_on_deadlock(). All db.api functions marked with this decorator will be retried if a DBDeadlock exception is received. Change-Id: I3488bfec67ec1c563292f1b61a7a9697f118809c Closes-bug: 1348588
* | Update Oslo imports to remove namespace packageDoug Hellmann2015-01-211-1/+1
|/ | | | | Change-Id: I4ec9b2a310471e4e07867073e9577731ac34027d Blueprint: drop-namespace-packages
* Move files out of the namespace packageDoug Hellmann2014-12-241-0/+229
Move the public API out of oslo.db to oslo_db. Retain the ability to import from the old namespace package for backwards compatibility for this release cycle. Blueprint: drop-namespace-packages Change-Id: Ie96b482b9fbcb1d85203ad35bb65c1f43e912a44
View Lorry Controller Status