distcloud/distributedcloud/requirements.txt
Robert Church 9180e7df84 Add various locking support to DCManager
Support the following lock updates in DCManager:
 - Provide a function decorator in common/utility.py for a synchronized
   lock that supports both external locks and internal fair locks. This
   decorator is setup, by default, for external locks.
 - Refactor update_subcloud_endpoint_status() so that a common private
   method is provided that is suitable for locking.
 - Update subcloud_manager.py to provide a function decorator to produce
   an internal fair lock based on a unique subcloud name. This decorator
   is specifically designed to be used with
   _update_subcloud_endpoint_status(). This will ensure that the
   multi-threaded DCManager process will only update subcloud endpoint
   information in a synchronized manner.
 - Provide an API lock to the SubcloudsController for the post, patch,
   and delete operations

Update distributedcloud requirements and spec file to require
oslo.concurrency >= 3.29.1. This is the latest version supported by the
Openstack Stein and is a version containing fair lock support.

Update unit tests:
 - Added unit test for update_subcloud_endpoint_status. This verifies
   high level functionality and the calling of fair locks based on the
   unique subcloud name.
 - Fixed intermittent failure seen when executing the add_subcloud unit
   test by mocking thread.Threading.
 - Leverage the use of oslo_concurrency's behavior to use the
   OSLO_LOCK_PATH environment variable if the lock_path config option is
   not set. Currently this is not set as we specify a hard coded
   external lock path at runtime. This allows us to set the lock path
   for tox tests via the test environment.

Change-Id: Id1902e8553408cbdd60b648efc39d59e8edcdb55
Depends-On: https://review.opendev.org/#/c/707188/
Closes-Bug: #1855359
Signed-off-by: Robert Church <robert.church@windriver.com>
2020-02-21 09:48:42 -05:00

51 lines
1.7 KiB
Plaintext

# 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.
# We have an older pbr which seems to work...
# pbr!=2.1.0,>=2.0.0 # Apache-2.0
pbr >= 1.8 # Apache-2.0
Babel!=2.4.0,>=2.3.4 # BSD
Paste # MIT
PasteDeploy>=1.5.0 # MIT
Routes>=2.3.1 # MIT
debtcollector>=1.2.0 # Apache-2.0
eventlet!=0.18.3,<0.21.0,>=0.18.2 # MIT
pecan!=1.0.2,!=1.0.3,!=1.0.4,!=1.2,>=1.0.0 # BSD
greenlet>=0.3.2 # MIT
httplib2>=0.7.5 # MIT
requests!=2.12.2,!=2.13.0,>=2.10.0 # Apache-2.0
Jinja2!=2.9.0,!=2.9.1,!=2.9.2,!=2.9.3,!=2.9.4,>=2.8 # BSD License (3 clause)
keystonemiddleware>=4.12.0 # Apache-2.0
netaddr!=0.7.16,>=0.7.13 # BSD
retrying!=1.3.0,>=1.2.3 # Apache-2.0
SQLAlchemy!=1.1.5,!=1.1.6,!=1.1.7,!=1.1.8,>=1.0.10 # MIT
WebOb>=1.7.1 # MIT
alembic>=0.8.10 # MIT
six>=1.9.0 # MIT
stevedore>=1.20.0 # Apache-2.0
oslo.concurrency>=3.29.1 # Apache-2.0
oslo.config>=4.0.0 # Apache-2.0
oslo.context>=2.14.0 # Apache-2.0
oslo.db>=4.21.1 # Apache-2.0
oslo.i18n!=3.15.2,>=2.1.0 # Apache-2.0
oslo.log>=3.22.0 # Apache-2.0
oslo.messaging!=5.25.0,>=5.24.2 # Apache-2.0
oslo.middleware>=3.27.0 # Apache-2.0
oslo.policy>=1.17.0 # Apache-2.0
oslo.rootwrap>=5.0.0 # Apache-2.0
oslo.serialization>=1.10.0 # Apache-2.0
oslo.service>=1.10.0 # Apache-2.0
oslo.utils>=3.20.0 # Apache-2.0
oslo.versionedobjects>=1.17.0 # Apache-2.0
sqlalchemy-migrate>=0.11.0 # Apache-2.0
python-openstackclient!=3.10.0,>=3.3.0 # Apache-2.0
python-neutronclient>=6.3.0 # Apache-2.0
python-cinderclient>=2.1.0 # Apache-2.0
python-novaclient>=7.1.0 # Apache-2.0
python-keystoneclient>=3.8.0 # Apache-2.0
pycrypto>=2.6 # Public Domain
pysnmp>=4.2.3 # BSD
requests_toolbelt