1ed9f9dac5
When the resource tracker has to lock a compute host for updates or inspection, it uses a single semaphore. In most cases, this is fine, as a compute process only is tracking one hypervisor. However, in Ironic, it's possible for one compute process to track many hypervisors. In this case, wait queues for instance claims can get "stuck" briefly behind longer processing loops such as the update_resources periodic job. The reason this is possible is because the oslo.lockutils synchronized library does not use fair locks by default. When a lock is released, one of the threads waiting for the lock is randomly allowed to take the lock next. A fair lock ensures that the thread that next requested the lock will be allowed to take it. This should ensure that instance claim requests do not have a chance of losing the lock contest, which should ensure that instance build requests do not queue unnecessarily behind long-running tasks. This includes bumping the oslo.concurrency dependency; fair locks were added in 3.29.0 (I37577becff4978bf643c65fa9bc2d78d342ea35a). Change-Id: Ia5e521e0f0c7a78b5ace5de9f343e84d872553f9 Related-Bug: #1864122
74 lines
2.4 KiB
Plaintext
74 lines
2.4 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.
|
|
|
|
pbr!=2.1.0,>=2.0.0 # Apache-2.0
|
|
SQLAlchemy>=1.2.19 # MIT
|
|
decorator>=3.4.0 # BSD
|
|
eventlet!=0.20.1,>=0.20.0 # MIT
|
|
Jinja2>=2.10 # BSD License (3 clause)
|
|
keystonemiddleware>=4.20.0 # Apache-2.0
|
|
lxml!=3.7.0,>=3.4.1 # BSD
|
|
Routes>=2.3.1 # MIT
|
|
cryptography>=2.7 # BSD/Apache-2.0
|
|
WebOb>=1.8.2 # MIT
|
|
# NOTE(mriedem): greenlet 0.4.14 does not work with older versions of gcc on
|
|
# ppc64le systems, see https://github.com/python-greenlet/greenlet/issues/136.
|
|
greenlet>=0.4.10,!=0.4.14 # MIT
|
|
PasteDeploy>=1.5.0 # MIT
|
|
Paste>=2.0.2 # MIT
|
|
PrettyTable<0.8,>=0.7.1 # BSD
|
|
sqlalchemy-migrate>=0.13.0 # Apache-2.0
|
|
netaddr>=0.7.18 # BSD
|
|
netifaces>=0.10.4 # MIT
|
|
paramiko>=2.0.0 # LGPLv2.1+
|
|
Babel!=2.4.0,>=2.3.4 # BSD
|
|
iso8601>=0.1.11 # MIT
|
|
jsonschema>=2.6.0 # MIT
|
|
python-cinderclient!=4.0.0,>=3.3.0 # Apache-2.0
|
|
keystoneauth1>=3.16.0 # Apache-2.0
|
|
python-neutronclient>=6.7.0 # Apache-2.0
|
|
python-glanceclient>=2.8.0 # Apache-2.0
|
|
requests>=2.14.2 # Apache-2.0
|
|
six>=1.10.0 # MIT
|
|
stevedore>=1.20.0 # Apache-2.0
|
|
websockify>=0.9.0 # LGPLv3
|
|
oslo.cache>=1.26.0 # Apache-2.0
|
|
oslo.concurrency>=3.29.0 # Apache-2.0
|
|
oslo.config>=6.1.0 # Apache-2.0
|
|
oslo.context>=2.21.0 # Apache-2.0
|
|
oslo.log>=3.36.0 # Apache-2.0
|
|
oslo.reports>=1.18.0 # Apache-2.0
|
|
oslo.serialization!=2.19.1,>=2.21.1 # Apache-2.0
|
|
oslo.upgradecheck>=0.1.1
|
|
oslo.utils>=3.40.2 # Apache-2.0
|
|
oslo.db>=4.44.0 # Apache-2.0
|
|
oslo.rootwrap>=5.8.0 # Apache-2.0
|
|
oslo.messaging>=10.3.0 # Apache-2.0
|
|
oslo.policy>=2.3.0 # Apache-2.0
|
|
oslo.privsep>=1.33.2 # Apache-2.0
|
|
oslo.i18n>=3.15.3 # Apache-2.0
|
|
oslo.service>=1.40.1 # Apache-2.0
|
|
rfc3986>=1.1.0 # Apache-2.0
|
|
oslo.middleware>=3.31.0 # Apache-2.0
|
|
psutil>=3.2.2 # BSD
|
|
oslo.versionedobjects>=1.35.0 # Apache-2.0
|
|
os-brick>=2.6.2 # Apache-2.0
|
|
os-resource-classes>=0.4.0 # Apache-2.0
|
|
os-traits>=2.1.0 # Apache-2.0
|
|
os-vif>=1.14.0 # Apache-2.0
|
|
os-win>=3.0.0 # Apache-2.0
|
|
castellan>=0.16.0 # Apache-2.0
|
|
microversion-parse>=0.2.1 # Apache-2.0
|
|
os-xenapi>=0.3.3 # Apache-2.0
|
|
tooz>=1.58.0 # Apache-2.0
|
|
cursive>=0.2.1 # Apache-2.0
|
|
pypowervm>=1.1.15 # Apache-2.0
|
|
retrying>=1.3.3,!=1.3.0 # Apache-2.0
|
|
os-service-types>=1.7.0 # Apache-2.0
|
|
taskflow>=2.16.0 # Apache-2.0
|
|
python-dateutil>=2.5.3 # BSD
|
|
zVMCloudConnector>=1.3.0;sys_platform!='win32' # Apache 2.0 License
|
|
futurist>=1.8.0 # Apache-2.0
|
|
openstacksdk>=0.35.0 # Apache-2.0
|