summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Prepare for using standard python testsmitaka-eolstable/mitakaAndreas Jaeger2017-02-062-0/+61
| | | | | | | | | | | | | | | | | | | Add simple script to setup mysql and postgresql databases, this script can be run by users during testing and will be run by CI systems for specific setup before running unit tests. This is exactly what is currently done by OpenStack CI in project-config. This allows to change in project-config the python-db jobs to python-jobs since python-jobs will call this script initially. See also http://lists.openstack.org/pipermail/openstack-dev/2016-November/107784.html Update CONTRIBUTING.rst for this. Needed-By: Ia298e25f9b15a2dcfc4553ea058fc2c0f3705a8b Change-Id: I825b72e3f645d02f7efdb3315a12825a8c937759 (cherry picked from commit 353ab3904749987841e72846098433fb957936fc)
* Updated from global requirementsOpenStack Proposal Bot2016-09-061-1/+1
| | | | Change-Id: I4e7b5178cc3b65c536b7283f9d7856cf81680661
* Capture DatabaseError for deadlock check4.7.1Kevin Benton2016-08-022-2/+3
| | | | | | | | | | | | 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)
* Catch empty value DBDuplicate errorsKevin Benton2016-07-062-2/+6
| | | | | | | | | | | | | | 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)
* Updated from global requirementsOpenStack Proposal Bot2016-04-291-1/+1
| | | | Change-Id: I210011f59398baa1403820f902aecbfecc7e62fd
* Updated from global requirementsOpenStack Proposal Bot2016-04-181-1/+1
| | | | Change-Id: I5c9f87a6faf5f7c95ca37bcfdae36fcd1b4db754
* Updated from global requirements4.7.0OpenStack Proposal Bot2016-03-241-1/+1
| | | | Change-Id: Iebf4727d600caf2066d1b807fc2ce94064ef77b8
* Update .gitreview for stable/mitakaDoug Hellmann2016-03-091-0/+1
| | | | Change-Id: I726bb77b74a5379272a5a4e2e052c24cd14473a5
* Merge "Increase the default max_overflow value"4.6.0Jenkins2016-02-242-0/+26
|\
| * Increase the default max_overflow valueRoman Podoliaka2016-02-242-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Merge "Clarify the types for retry_interval args of wrap_db_retry"Jenkins2016-02-241-3/+4
|\ \ | |/ |/|
| * 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
* | Updated from global requirementsOpenStack Proposal Bot2016-02-241-1/+1
| | | | | | | | Change-Id: I76462ae49dc4d102c24430a9382150001ee01cbb
* | add reno for release notes managementDoug Hellmann2016-02-239-0/+304
| | | | | | | | | | Change-Id: I6574d2bb21fa8c64290b06ab493f8f7c8b1b7c16 Signed-off-by: Doug Hellmann <doug@doughellmann.com>
* | Updated from global requirementsOpenStack Proposal Bot2016-02-201-1/+1
| | | | | | | | Change-Id: I122380ae921422083529f892ae28eb628ff802fc
* | Updated from global requirementsOpenStack Proposal Bot2016-02-191-1/+1
|/ | | | Change-Id: Ic7047825c790913cc988c9a6739ab882dba6d568
* Merge "stop making a copy of options discovered by config generator"4.5.0Jenkins2016-02-121-3/+1
|\
| * stop making a copy of options discovered by config generatorDoug Hellmann2016-02-101-3/+1
| | | | | | | | | | | | | | | | | | | | 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>
* | Updated from global requirementsOpenStack Proposal Bot2016-02-111-1/+1
|/ | | | Change-Id: Icb8474b007085b0b803fd1413026fa3dd8f68d34
* exceptions: provide .message attribute for Py3K compatibility4.4.0Roman Podoliaka2016-02-082-0/+21
| | | | | | | | | | | | | | | | | 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
* Updated from global requirementsOpenStack Proposal Bot2016-02-081-1/+1
| | | | Change-Id: I1103fed62ae10b1b53f4478022c9ac7e28799695
* InvalidSortKey constructor change breaks Heat unittestsDavanum Srinivas2016-02-062-1/+3
| | | | | | | | Just supply a default value None, to avoid breaking projects who currently use this exception. Closes-Bug: #1542671 Change-Id: Ia397cab309aa22a2a86964f2ff90a796c878b2e7
* Merge "exception: fix DBInvalidUnicodeParameter error message"Jenkins2016-02-052-2/+8
|\
| * exception: fix DBInvalidUnicodeParameter error messageJulien Danjou2016-02-042-2/+8
| | | | | | | | Change-Id: I1455f55929aa3a6037138770d407d247397c062b
* | Merge "exceptions: enhance InvalidSortKey to carry the invalid key"Jenkins2016-02-053-5/+6
|\ \ | |/
| * exceptions: enhance InvalidSortKey to carry the invalid keyJulien Danjou2016-02-023-5/+6
| | | | | | | | Change-Id: I6bb1b567cf962fd1c694d112a15e830367af2889
* | Merge "exception: fix InvalidSortKey message"Jenkins2016-02-052-1/+7
|\ \ | |/
| * exception: fix InvalidSortKey messageJulien Danjou2016-02-012-1/+7
| | | | | | | | Change-Id: I0e11ee6ffc56ee0399ad930fc9da49c7f16ca67b
* | Merge "Add exc_filter for invalid Unicode string"Jenkins2016-02-032-0/+27
|\ \ | |/ |/|
| * Add exc_filter for invalid Unicode stringEric Harney2016-01-252-0/+27
| | | | | | | | | | | | | | | | | | | | 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
* | Update translation setupAkihiro Motoki2016-01-2918-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Updated from global requirementsOpenStack Proposal Bot2016-01-261-1/+1
|/ | | | Change-Id: Ie8d50f948f85edf6e8dbafe944e239cfd415dd34
* Updated from global requirementsOpenStack Proposal Bot2016-01-241-1/+1
| | | | Change-Id: I98da614e5336d531bb6d69a8dd08d454b20fd6f6
* Updated from global requirementsOpenStack Proposal Bot2016-01-231-1/+1
| | | | Change-Id: I7cfce3d16572519bcc3487c32dac46c2b950c54b
* Updated from global requirementsOpenStack Proposal Bot2016-01-211-1/+1
| | | | Change-Id: I86c118bdcd2f95fff0eaaefcc62ec3a09a40e794
* Merge "Don't log non-db error in retry wrapper"4.3.1Jenkins2016-01-202-5/+12
|\
| * Don't log non-db error in retry wrapperMatt Riedemann2016-01-132-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Imported Translations from ZanataOpenStack Proposal Bot2016-01-1713-97/+100
| | | | | | | | | | | | | | For more information about this automatic import see: https://wiki.openstack.org/wiki/Translations/Infrastructure Change-Id: I73c4b3c1a9893779d3526ad048e09a76f870321f
* | Updated from global requirementsOpenStack Proposal Bot2016-01-172-20/+20
| | | | | | | | Change-Id: I94f7328437266d6dbaece5e6b2f21a0ea700064e
* | Fix tests to work under both pymsysql 0.6.2 and 0.7.xDavanum Srinivas2016-01-151-3/+8
|/ | | | | | | | | | | | | | | | | | | | 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
* Updated from global requirements4.3.0OpenStack Proposal Bot2016-01-061-2/+2
| | | | Change-Id: Ic7ab3b9e6dc8354861be1af46210269f74c04333
* Merge "Put py34 first in the env order of tox"Jenkins2015-12-291-1/+1
|\
| * Put py34 first in the env order of toxJanonymous2015-12-221-1/+1
| | | | | | | | | | | | | | | | | | | | 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
* | Updated from global requirementsOpenStack Proposal Bot2015-12-211-1/+1
|/ | | | Change-Id: I6d23bee6e6e9b0a7a6dcb20edb8ef4476c2d561e
* Fix comparison of Variant and other type in compare_type4.2.0AKamyshnikova2015-12-192-1/+18
| | | | | | | | | 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
* Updated from global requirementsOpenStack Proposal Bot2015-12-151-1/+1
| | | | Change-Id: I1f3e785a9e7344279c2d4176f67678be564169d1
* Updated from global requirementsOpenStack Proposal Bot2015-12-111-1/+1
| | | | Change-Id: I37020a0bfbcd19a99af5a9b090d81d60fee54d74
* 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
* Merge "Trival: Remove 'MANIFEST.in'"Jenkins2015-12-081-6/+0
|\
| * Trival: Remove 'MANIFEST.in'ChangBo Guo(gcb)2015-12-051-6/+0
| | | | | | | | | | | | | | | | | | 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
View Lorry Controller Status