Currently InternalError is being handled for detecting MariaDB/Galera
deadlocks but recently we have seen a variant that raises
OperationalError instead. Because it's not being detected, usage of the
@retry_on_deadlock decorator is not performing retries in those cases.
This adds handling of OperationalError for detecting this deadlock.
Closes-Bug: #2057987
Change-Id: I6ff3667b35ea38a2d3c258f810a55eda9abe465e
Add file to the reno documentation build to show release notes for
stable/2024.1.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/2024.1.
Sem-Ver: feature
Change-Id: I66efd50c02dc7aa582a6398f23e8230221baa912
The previous attempt did not update the version in pre commit config
so the old version is still used by pep8 target.
Change-Id: Ib4b2ee82bab8410b0b1f3a1e8a4e53cfb165e1d5
As per the current release tested runtime, we test
python version from 3.8 to 3.11 so updating the
same in python classifier in setup.cfg
Change-Id: I303a0fbe36a1ca7ae7b9b6e82972da3107f58d0c
This change resolves the following warning detected by zuul.
All regular expressions must conform to RE2 syntax, but an
expression using the deprecated Perl-style syntax has been detected.
Adjust the configuration to conform to RE2 syntax.
The RE2 syntax error is: invalid perl operator: (?!
Change-Id: Iddb5224b6e2f32a0c26f348ae3acc884b8d9b53b
Debian Bookworm switched from MySQL to MariaDB.
Change-Id: Id5f64a5cedd45769188be12fb5df8e43b2abcb1d
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Add file to the reno documentation build to show release notes for
stable/2023.2.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/2023.2.
Sem-Ver: feature
Change-Id: Icbb93217de7bb305596077eaee3c4f862b0894e6
So we know if we can remove this in the future, or at least have context
around why it's there.
Change-Id: I4e4bdcd6a01e8c1071045bbe1310cbdf4195ec27
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This has been deprecated for some time now.
Change-Id: Ia8b4ed8cd755d283bb773e55293457190b34c482
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Resolve the following SAWarning warning:
SAWarning: Attribute '_expr_to_appease_mox' on class <class
'oslo_db.tests.sqlalchemy.test_utils.FakeTable'> appears to be a
non-schema SQLAlchemy expression object; this won't be part of the
declarative mapping. To map arbitrary expressions, use
``column_property()`` or a similar function such as ``deferred()``,
``query_expression()`` etc.
Change-Id: I7baac158e5987d95f6272d9849c5ec6a2071a25f
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
We're seeing a weird condition whereby the exceptions raised by our
exception handler and being "rehandled", resulting in 'DBError' being
raised instead of e.g. 'DBReferenceError'. This is hard to reproduce and
thus far has only be spotted in Barbican unit tests. Prevent the issue
by checking if the exception being handled is one of our own and skip
handling it if so.
Change-Id: Ibd3f665a3ed3aedf9d1f33edcab35a46c27ea3dc
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Alembic was previously modifying the metadata server default when
comparing it in the autogenerate process. This was removed in Alembic
1.11. As noted in the commit message [1], we implement our own
'compare_server_default' which means we now need to handle this.
[1] https://github.com/sqlalchemy/alembic/commit/230a2932f6
Change-Id: Ib5f8f78b917d79c4c234cc689c13acff011c2403
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
If an option is deprecated, there's a good chance we want to ignore it
unless explicitly requested by the user. Start ignoring options that are
deprecated and unset.
Change-Id: I3008562db52a5625504b262d7148528a832246dd
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Closes-Bug: #2008720
In change I1e71150ba6daeba464b6ed8d46163f1f34959db3 we removed the
legacy base test classes, first deprecated in 2015. We forgot to include
a release note, however. Address this now.
Change-Id: I4d66f0308b89a187143ef6c8495383fe60043c14
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Change I8629225eeb51d95264d8a3e4b719268bb1597f4f bumped the minimum
version for SQLAlchemy to 1.4, meaning this logic is now dead. Remove
it.
Change-Id: I4d4a58e15e840ecfa63e15c709617a65642c8323
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
We were creating regexes without the DOTALL flag, which meant '.' wasn't
matching newlines. This meant exceptions that contained multiple lines
would not be caught. For example, in my environment where Kerberos is
used, I see the following otherwise harmless message:
(psycopg2.OperationalError) connection to server at "localhost" (::1),
port 5432 failed: could not initiate GSSAPI security context: No
credentials were supplied, or the credentials were unavailable or
inaccessible: Configuration file does not specify default realm
connection to server at "localhost" (::1), port 5432 failed: FATAL:
database "non_existent_database" does not exist
The presence of that newline causes our matchers to fail and the
exception is not wrapped. Correct this.
In the meanwhile, we reformat the function that does the wrapping to
make it a little flatter. This was difficult to modify (for debugging
purposes) due to the level of indentation.
Change-Id: I5396a5a3272e6984954d819cfc71507283c775db
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This should have been removed in change
Ic3d6bd318038d723b0d50d39e45f8e26289e9a57 but was missed.
Change-Id: I4e1faa2c617ac19e7c9766e99ee9012ad9298d31
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Mock it out, reducing test run of ~3 and ~15 seconds to milliseconds.
Change-Id: Ice3a0c0d0a5b8c2920c7f775ff8ce974b572c66e
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Within 2023.2 python version 3.9 and 3.10 are the
supported python runtimes [1].
[1] https: //review.opendev.org/c/openstack/governance/+/872232
Change-Id: I0cb0d4e03858a4f394aed484508b305683ce7863
Add two new jobs to verify the main branches of these two projects. This
should keep us on top of things.
Change-Id: Iaa955e6d5563c97ab5cc64fe9133db63d6489a0e
Depends-on: https://review.opendev.org/c/openstack/project-config/+/879549
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This functionality has been available upstream since SQLALchemy 1.2 [1].
However, for oslo.db to use this feature while maintaining full
behavior, we need at least SQLAlchemy 2.0.5 to provide complete event
support. In particular, oslo.db adds several new "is disconnect"
conditions including those specific to Galera.
Behavior of the handle_error event is modified to expect the "pre-ping"
calling form, which may not have an "engine" present (only a dialect),
and additionally takes advantage of the new is_pre_ping attribute which
informs on the correct way to affect the disconnection status within the
ping handler.
Change-Id: I50d862d3cbb126987a63209795352c6e801ed919
Remaining issues encountered when running with SQLAlchemy 2.0 for real:
* Never call str() on a URL and expect it to be meaningful anymore.
The password is aggressively obfuscated now (users absolultely
wouldn't let us leave it as is)
* More utilities and fixtures that were calling begin() within a
block that would have already begun
* isnot is now called is_not; mocking "isnot" leads into too many
weird compat layers
* ORM InstrumentedAttribute and internals use __slots__ now, mock
seems to not be able to patch methods. Ideally these tests would use
a comparator subclass or something
* Connection.connection.connection is now called driver_connection,
SQLAlchemy keeps the old name available however oslo.db test suite
does not appear to tolerate the deprecation warning emitted,
so add a compat layer
* mapper() is fully removed from 2.0, not sure if there is another
not-yet-committed gerrit that removes mapper()
[1] https://docs.sqlalchemy.org/en/20/core/engines.html#sqlalchemy.create_engine.params.pool_pre_ping
[2] https://docs.sqlalchemy.org/en/20/changelog/changelog_20.html#change-2fe37eaf2295cebd3bb4ee8e5b8c575c
[3] https://github.com/sqlalchemy/sqlalchemy/issues/5648
Change-Id: Ifaca67c07f008d8bc0febeecd3e200cc7ee7a4b0