a7bccff06b
We discovered that two unit test cases added in I0647bb8545c1464b521a1d866cf5ee674aea2eae cause errors like oslo_db.sqlalchemy.enginefacade.AlreadyStartedError: this TransactionFactory is already started when the db tests run selectively with tox -e py38 nova.tests.unit.db but does not cause errors if the whole unit test suit is run. This error happened because our db code uses two global transaction factory, one for the api DB and one for the main DB. There was a global flag SESSION_CONFIGURED in our Database fixture that guarded against double initialization of the factory. But the faulty test cases in question do not use our Database fixture but use the OpportunisticDBTestMixin from oslo_db. Obviously that fixture does not know about our SESSION_CONFIGURED global. So if one of the offending test case ran first in an executor then that initialized the transaction factory globally and a later test that uses our Database fixture tried to configure it again leading to the error. For some unknown reason if these tests were run in the opposite order the faulty re-initialization did not happen. Probably the OpportunisticDBTestMixin was able to prevent that. A previous patch already removed the global SESSION_CONFIGURED flag from our fixture and replaced it with a per DB specific patch_factory calls that allow resetting the state of the factory at the end of each test case. This would already solve the current test case issue as only our offending test cases would initialize the global factory without cleanup and we have one test case per DB. So there would be no interference. However if in the future we add similar test cases then those can still interfere through the global factory. So this patch fixes the two offending test case. Also it extends the DatabasePoisonFixture used for the NoDbTestCase tesst. The poison now detects if the test case starts any transaction factory. This poison caught another offender test case, test_db_sync_with_special_symbols_in_connection_string, that was marked NoDb but actually using the database. It is now changed to declare itself as a test that sets up the DB manually and also it is changed to use the Database fixture instead of touching the global factory directly. Closes-Bug: #1948963 Change-Id: Id96f1795034490c13125ebbab49b029fb96af1c7
OpenStack Nova
OpenStack Nova provides a cloud computing fabric controller, supporting a wide variety of compute technologies, including: libvirt (KVM, Xen, LXC and more), Hyper-V, VMware, OpenStack Ironic and PowerVM.
Use the following resources to learn more.
API
To learn how to use Nova's API, consult the documentation available online at:
For more information on OpenStack APIs, SDKs and CLIs in general, refer to:
Operators
To learn how to deploy and configure OpenStack Nova, consult the documentation available online at:
In the unfortunate event that bugs are discovered, they should be reported to the appropriate bug tracker. If you obtained the software from a 3rd party operating system vendor, it is often wise to use their own bug tracker for reporting problems. In all other cases use the master OpenStack bug tracker, available at:
Developers
For information on how to contribute to Nova, please see the contents of the CONTRIBUTING.rst.
Any new code must follow the development guidelines detailed in the HACKING.rst file, and pass all unit tests.
Further developer focused documentation is available at:
Other Information
During each Summit and Project Team Gathering, we agree on what the whole community wants to focus on for the upcoming release. The plans for nova can be found at: