| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
Pymysql can raise 'lock wait timeout exceeded' errors
as InternalErrors. The previous filter was only catching
OperationalError exceptions. This patch changes it to
catch all DatabaseErrors, which both of the aforementioned
exceptions inherit.
Change-Id: If7bd1ceef6e5d64f0766b780616388c62862ce82
Closes-Bug: #1608691
(cherry picked from commit 3277ef33f2a1f6a892f0832e2907acef7b45dc2b)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can have integrity constraint violations when the
value is an empty string. The previous regex for converting
these into DBDuplicate exceptions was not considering this
case.
This adjusts the regex to a 0 or many instead of a 1 or many
match for the value and adds a case to a test.
Change-Id: Ibf4686f92fcffb8e70ec2735ab878e8849ed37b1
Closes-Bug: #1599086
(cherry picked from commit 16886e55bd8fde77f71d75c3c87c2f71ee6dbd4f)
|
|
|
|
| |
Change-Id: I210011f59398baa1403820f902aecbfecc7e62fd
|
|
|
|
| |
Change-Id: I5c9f87a6faf5f7c95ca37bcfdae36fcd1b4db754
|
|
|
|
| |
Change-Id: Iebf4727d600caf2066d1b807fc2ce94064ef77b8
|
|
|
|
| |
Change-Id: I726bb77b74a5379272a5a4e2e052c24cd14473a5
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It turned out that distribution of WSGI requests between forks is not
even when eventlet is used, which can cause pool timeout issues under
load, while there are idle workers with open DB connections, which
should have served these HTTP requests.
The default max_overflow value should be increased to allow DB oriented
services (mostly APIs) handle spikes in number of concurrent requests
trying to use a DB.
At the same time, the default number of greenlets is decreased:
I65b40b9906b75146a0085bbe168f1e6bcae82f21
which effectively causes a particular worker to stop accepting new
requests it has no resources (DB connections) to handle and allow
other forks accept()'ing on the same FD to proceed.
Testing was performed using this script:
https://gist.github.com/zzzeek/c69138fd0d0b3e553a1f
With 100 greenthreads in the pool, 50 DB connections allowed overflow
no pool timeout issues were seen with up to 500 concurrent requests
done by ab, while current default values (1000/10) could not handle
even 100 concurrent requests.
See this ML thread for details:
http://lists.openstack.org/pipermail/openstack-dev/2015-December/082717.html
DocImpact
This change potentially increases the number of connections open to the
RDBMS server. If you start seeing "too many connections" errors, please
check these settings and adjust them appropriately:
https://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_max_connections
http://www.postgresql.org/docs/current/static/runtime-config-connection.html#GUC-MAX-CONNECTIONS
Closes-Bug: #1535375
Change-Id: I2e9c2a71d8231e0dfbefc6293ad319e1e459beec
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| | |
Change-Id: I76462ae49dc4d102c24430a9382150001ee01cbb
|
| |
| |
| |
| |
| | |
Change-Id: I6574d2bb21fa8c64290b06ab493f8f7c8b1b7c16
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
|
| |
| |
| |
| | |
Change-Id: I122380ae921422083529f892ae28eb628ff802fc
|
|/
|
|
| |
Change-Id: Ic7047825c790913cc988c9a6739ab882dba6d568
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In order for the config generator's new hook for updating default values
to work, we have to return the same Opt objects from list_opts() that
our set_defaults() function is going to modify. There's no real need to
be making copies of the objects anyway, so just stop doing it.
Change-Id: I62c2f733f1e7943449aa744ed15dac4addb3e1f7
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
|
|/
|
|
| |
Change-Id: Icb8474b007085b0b803fd1413026fa3dd8f68d34
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In two recent commits we fixed the way .message class attribute was
used by passing it as an argument to __init__() of the base Exception
class instead.
Unfortunately, this currently breaks Heat unit tests on Py3K as
exception instances no longer provide .message attribute there.
Re-introduce .message properties only for exception classes that used
to have them to ensure the new oslo.db release do not change the
interface of exceptions.
Closes-Bug: #1542961
Change-Id: I5cae408555956d77e6cbb4e5e513c1c6c375d29d
|
|
|
|
| |
Change-Id: I1103fed62ae10b1b53f4478022c9ac7e28799695
|
|
|
|
|
|
|
|
| |
Just supply a default value None, to avoid breaking projects
who currently use this exception.
Closes-Bug: #1542671
Change-Id: Ia397cab309aa22a2a86964f2ff90a796c878b2e7
|
|\ |
|
| |
| |
| |
| | |
Change-Id: I1455f55929aa3a6037138770d407d247397c062b
|
|\ \
| |/ |
|
| |
| |
| |
| | |
Change-Id: I6bb1b567cf962fd1c694d112a15e830367af2889
|
|\ \
| |/ |
|
| |
| |
| |
| | |
Change-Id: I0e11ee6ffc56ee0399ad930fc9da49c7f16ca67b
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This error occurs if passing a Unicode string to the
database which cannot be stored (i.e. it contains chars
>4 bytes long and the db is not configured to handle
that).
Change-Id: I12311909dec6e447c93917a5efd68599f35c4b89
Related-Bug: #1393871
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Follow new infra setup for translations, see spec
http://specs.openstack.org/openstack-infra/infra-specs/specs/translation_setup.html
for full details.
This basically renames oslo.db/locale/oslo.db.pot to
oslo_db/locale/oslo_db.pot.
For this we need to update setup.cfg.
Update also domain name in _i18n.py.
Change-Id: I5b3052f840201557f3b1c85effeda3bb3318a9ee
|
|/
|
|
| |
Change-Id: Ie8d50f948f85edf6e8dbafe944e239cfd415dd34
|
|
|
|
| |
Change-Id: I98da614e5336d531bb6d69a8dd08d454b20fd6f6
|
|
|
|
| |
Change-Id: I7cfce3d16572519bcc3487c32dac46c2b950c54b
|
|
|
|
| |
Change-Id: I86c118bdcd2f95fff0eaaefcc62ec3a09a40e794
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| |
| | |
For more information about this automatic import see:
https://wiki.openstack.org/wiki/Translations/Infrastructure
Change-Id: I73c4b3c1a9893779d3526ad048e09a76f870321f
|
| |
| |
| |
| | |
Change-Id: I94f7328437266d6dbaece5e6b2f21a0ea700064e
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In 0.6.2, the exc.statement and exc.params were as follows:
exc.statement = {unicode} u'INSERT INTO resource_entity (id, foo_id)
VALUES (%s, %s)'
exc.params = {tuple} (1, 2)
In 0.7.1, the exc.statement and exc.params are as follows:
exc.statement = {unicode} u'INSERT INTO resource_entity (id, foo_id)
VALUES (%(id)s, %(foo_id)s)'
exc.params = {dict} {'id': 1, 'foo_id': 2}
So the easiest thing to support both is to use string interpolation
and then check if they are equal. This approach works for both py34
and py27 as well. Note that we still have to test the old way for
sqlite which has (?, ?) in the SQL statement.
Closes-Bug: #1533861
Change-Id: Iab9f0e4b4dd337363dd7e705c1155f3f6517b404
|
|
|
|
| |
Change-Id: Ic7ab3b9e6dc8354861be1af46210269f74c04333
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
To solve the problem of "db type could
not be determined" on py34 we have to run first the py34 env to, then, run
py27. This patch puts py34 first on the tox.ini list of envs to avoid this
problem to happen.
Change-Id: I2365f66eee43cd36e62fe05e582c328787a0a112
Closes-bug: #1489059
|
|/
|
|
| |
Change-Id: I6d23bee6e6e9b0a7a6dcb20edb8ef4476c2d561e
|
|
|
|
|
|
|
|
|
| |
Neutron hit problem with comparison Variant type and BigInteger.
Seems that comparison with Variant is not done properly so add
correction of it in compare_type.
Change-Id: Ic5279fcf11cf9123d007010d094a7f255ba0555e
Related-bug: #1526675
|
|
|
|
| |
Change-Id: I1f3e785a9e7344279c2d4176f67678be564169d1
|
|
|
|
| |
Change-Id: I37020a0bfbcd19a99af5a9b090d81d60fee54d74
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Everything in this file is automatically generated by pbr. There
appears to be no good reason to keep it around.
More details please see:
https://github.com/openstack-dev/pbr/blob/master/pbr/packaging.py#L384
Change-Id: I48e3a0129949747759acb68984f1e0425185e032
|
|\ \ |
|
| |/
| |
| |
| |
| |
| | |
We don't use it in anywhere.
Change-Id: I411755e8297459b9b726cb7235da08236d098455
|