commit 0372d82c2c5ae5651b00c5ab9e1cf5c77a8f87d9
Author: Chris Dent <email address hidden>
Date: Fri Mar 16 16:54:14 2018 +0000
Ensure that os-traits sync is attempted only at start of process
Traits sync had been tried any time a request that might involve
traits was called. If the global was set no syncing was done, but
lock handling was happening.
This change moves the syncing into the the deploy.load_app() handling.
This means that the syncing will be attempted any time a new WSGI
application is created. Most of the time this will be at the start of a
new process, but some WSGI servers have interesting threading models so
there's a (slim) possibility that it could be in a thread. Because of
this latter possibility, the locking is still in place.
Functional tests are updated to explicitly do the sync in their
setUp(). Some changes in fixtures are required to make sure that
the database is present prior to the sync.
While these changes are not strictly part of extracting placement, the
consolidation and isolation of database handling code makes where to put
this stuff a bit cleaner and more evident: an update_database() method
in deploy uses an empty DbContext class from db_api to the call the
ensure_trait_sync method in resource_provider. update_database is in
deploy because it an app deployment task and because putting it in
db_api leads to circual import problems.
Reviewed: https:/ /review. openstack. org/553857 /git.openstack. org/cgit/ openstack/ nova/commit/ ?id=0372d82c2c5 ae5651b00c5ab9e 1cf5c77a8f87d9
Committed: https:/
Submitter: Zuul
Branch: master
commit 0372d82c2c5ae56 51b00c5ab9e1cf5 c77a8f87d9
Author: Chris Dent <email address hidden>
Date: Fri Mar 16 16:54:14 2018 +0000
Ensure that os-traits sync is attempted only at start of process
Traits sync had been tried any time a request that might involve
traits was called. If the global was set no syncing was done, but
lock handling was happening.
This change moves the syncing into the the deploy.load_app() handling.
This means that the syncing will be attempted any time a new WSGI
application is created. Most of the time this will be at the start of a
new process, but some WSGI servers have interesting threading models so
there's a (slim) possibility that it could be in a thread. Because of
this latter possibility, the locking is still in place.
Functional tests are updated to explicitly do the sync in their
setUp(). Some changes in fixtures are required to make sure that
the database is present prior to the sync.
While these changes are not strictly part of extracting placement, the trait_sync method in resource_provider. update_database is in
consolidation and isolation of database handling code makes where to put
this stuff a bit cleaner and more evident: an update_database() method
in deploy uses an empty DbContext class from db_api to the call the
ensure_
deploy because it an app deployment task and because putting it in
db_api leads to circual import problems.
blueprint placement-extract
Closes-Bug: #1756151
Change-Id: Ic87518948ed5bf 4ab79f9819cd947 14e350ce265