49e085583d
One of the major changes in SQLAlchemy 2.0 is the removal of autocommit support. It turns out Ironic was using this quite aggressively without even really being aware of it. * Moved the declaritive_base to ORM, as noted in the SQLAlchemy 2.0 changes[0]. * Console testing caused us to become aware of issues around locking where session synchronization, when autocommit was enabled, was defaulted to False. The result of this is that you could have two sessions have different results, which could results on different threads, and where one could still attempt to lock based upon prior information. Inherently, while this basically worked, it was also sort of broken behavior. This resulted in locking being rewritten to use the style mandated in SQLAlchemy 2.0 migration documentation. This ultimately is due to locking, which is *heavily* relied upon in Ironic, and in unit testing with sqlite, there are no transactions, which means we can get some data inconsistency in unit testing as well if we're reliant upon the database to precisely and exactly return what we committed.[1] * Begins changing the query.one()/query.all() style to use explicit select statements as part of the new style mandated for migration to SQLAlchemy 2.0. * Instead of using field label strings for joined queries, use the object format, which makes much more sense now, and is part of the items required for eventual migration to 2.0. * DB queries involving Traits are now loaded using SelectInLoad as opposed to Joins. The now deprecated ORM queries were quietly and silently de-duplicating rows and providing consistent sets from the resulting joined table responses, however putting much higher CPU load on the processing of results on the client. Prior performance testing has informed us this should be a minimal overhead impact, however these queries should no longer be in transactions with the Database Servers which should offset the shift in load pattern. The reason we cannot continue to deduplicate locally in our code is because we carry Dict data sets which cannot be hashed for deduplication. Most projects have handled this by treating them as Text and then converting, but without a massive rewrite, this seems to be the viable middle ground. * Adds an explict mapping for traits and tags on the Node object to point directly to the NodeTrait and NodeTag classes. This superceeds the prior usage of a backref to make the association. * Splits SQLAlchemy class model Node into Node and NodeBase, which allows for high performance queries to skip querying for ``tags`` and ``traits``. Otherwise with the afrormentioned lookups would always execute as they are now properties as well on the Node class. This more common of a SQLAlchemy model, but Ironic's model has been a bit more rigid to date. * Adds a ``start_consoles`` and ``start_allocations`` option to the conductor ``init_host`` method. This allows unit tests to be executed and launched with the service context, while *not* also creating race conditions which resulted in failed tests. * The db API ``_paginate_query`` wrapper now contains additional logic to handle traditional ORM query responses and the newer style of unified query responses. Due to differences in queries and handling, which also was part of the driver for the creation of ``NodeBase``, as SQLAlchemy will only create an object if a base object is referenced. Also, by default, everything returned is a tuple in 1.4 with the unified interface. * Also modified one unit test which counted time.sleep calls, which is a known pattern which can create failures which are ultimately noise. Ultimately, I have labelled the remaining places which SQLAlchemy warnings are raised at for deprecation/removal of functionality, which needs to be addressed. [0] https://docs.sqlalchemy.org/en/14/changelog/migration_20.html [1] https://docs.sqlalchemy.org/en/14/dialects/sqlite.html#transaction-isolation-level-autocommit Change-Id: Ie0f4b8a814eaef1e852088d12d33ce1eab408e23
51 lines
1.8 KiB
Plaintext
51 lines
1.8 KiB
Plaintext
# Requirements lower bounds listed here are our best effort to keep them up to
|
|
# date but we do not test them so no guarantee of having them all correct. If
|
|
# you find any incorrect lower bounds, let us know or propose a fix.
|
|
|
|
# The order of packages is significant, because pip processes them in the order
|
|
# of appearance. Changing the order has an impact on the overall integration
|
|
# process, which may cause wedges in the gate later.
|
|
pbr>=3.1.1 # Apache-2.0
|
|
SQLAlchemy>=1.4.0 # MIT
|
|
alembic>=1.4.2 # MIT
|
|
automaton>=1.9.0 # Apache-2.0
|
|
eventlet!=0.18.3,!=0.20.1,>=0.18.2 # MIT
|
|
WebOb>=1.7.1 # MIT
|
|
python-cinderclient!=4.0.0,>=3.3.0 # Apache-2.0
|
|
python-glanceclient>=2.8.0 # Apache-2.0
|
|
keystoneauth1>=4.2.0 # Apache-2.0
|
|
ironic-lib>=4.6.1 # Apache-2.0
|
|
python-swiftclient>=3.2.0 # Apache-2.0
|
|
pytz>=2013.6 # MIT
|
|
stevedore>=1.29.0 # Apache-2.0
|
|
oslo.concurrency>=4.2.0 # Apache-2.0
|
|
oslo.config>=6.8.0 # Apache-2.0
|
|
oslo.context>=2.22.0 # Apache-2.0
|
|
oslo.db>=9.1.0 # Apache-2.0
|
|
oslo.rootwrap>=5.8.0 # Apache-2.0
|
|
oslo.log>=4.3.0 # Apache-2.0
|
|
oslo.middleware>=3.31.0 # Apache-2.0
|
|
oslo.policy>=3.7.0 # Apache-2.0
|
|
oslo.serialization>=2.25.0 # Apache-2.0
|
|
oslo.service!=1.28.1,>=1.24.0 # Apache-2.0
|
|
oslo.upgradecheck>=1.3.0 # Apache-2.0
|
|
oslo.utils>=4.5.0 # Apache-2.0
|
|
osprofiler>=1.5.0 # Apache-2.0
|
|
os-traits>=0.4.0 # Apache-2.0
|
|
pecan!=1.0.2,!=1.0.3,!=1.0.4,!=1.2,>=1.0.0 # BSD
|
|
pycdlib>=1.11.0 # LGPLv2
|
|
requests>=2.18.0 # Apache-2.0
|
|
rfc3986>=1.2.0 # Apache-2.0
|
|
jsonpatch!=1.20,>=1.16 # BSD
|
|
Jinja2>=3.0.0 # BSD License (3 clause)
|
|
keystonemiddleware>=9.5.0 # Apache-2.0
|
|
oslo.messaging>=5.29.0 # Apache-2.0
|
|
tenacity>=6.2.0 # Apache-2.0
|
|
oslo.versionedobjects>=1.31.2 # Apache-2.0
|
|
jsonschema>=3.2.0 # MIT
|
|
psutil>=3.2.2 # BSD
|
|
futurist>=1.2.0 # Apache-2.0
|
|
tooz>=2.7.0 # Apache-2.0
|
|
openstacksdk>=0.48.0 # Apache-2.0
|
|
sushy>=4.3.0
|