neutron/requirements.txt

66 lines
2.1 KiB
Plaintext
Raw Normal View History

# 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>=4.0.0 # Apache-2.0
Paste>=2.0.2 # MIT
PasteDeploy>=1.5.0 # MIT
Routes>=2.3.1 # MIT
debtcollector>=1.19.0 # Apache-2.0
decorator>=4.1.0 # BSD
eventlet>=0.26.1 # MIT
pecan>=1.4.0 # BSD
httplib2>=0.9.1 # MIT
requests>=2.18.0 # Apache-2.0
Jinja2>=2.10 # BSD License (3 clause)
keystonemiddleware>=5.1.0 # Apache-2.0
netaddr>=0.7.18 # BSD
netifaces>=0.10.4 # MIT
neutron-lib>=3.6.1 # Apache-2.0
python-neutronclient>=7.8.0 # Apache-2.0
tenacity>=6.0.0 # Apache-2.0
SQLAlchemy>=1.4.23 # MIT
WebOb>=1.8.2 # MIT
keystoneauth1>=3.14.0 # Apache-2.0
alembic>=1.6.5 # MIT
stevedore>=2.0.1 # Apache-2.0
oslo.cache>=1.26.0 # Apache-2.0
oslo.concurrency>=3.26.0 # Apache-2.0
oslo.config>=9.0.0 # Apache-2.0
oslo.context>=2.22.0 # Apache-2.0
oslo.db>=4.44.0 # Apache-2.0
oslo.i18n>=3.20.0 # Apache-2.0
oslo.log>=4.5.0 # Apache-2.0
oslo.messaging>=7.0.0 # Apache-2.0
oslo.middleware>=3.31.0 # Apache-2.0
oslo.policy>=3.12.0 # Apache-2.0
oslo.privsep>=2.3.0 # Apache-2.0
oslo.reports>=1.18.0 # Apache-2.0
oslo.rootwrap>=5.15.0 # Apache-2.0
oslo.serialization>=2.25.0 # Apache-2.0
oslo.service>=2.8.0 # Apache-2.0
oslo.upgradecheck>=1.3.0 # Apache-2.0
oslo.utils>=4.8.0 # Apache-2.0
oslo.versionedobjects>=1.35.1 # Apache-2.0
osprofiler>=2.3.0 # Apache-2.0
os-ken>=2.2.0 # Apache-2.0
os-resource-classes>=1.1.0 # Apache-2.0
ovs>=2.10.0 # Apache-2.0
ovsdbapp>=2.2.1 # Apache-2.0
packaging>=20.4 # Apache-2.0
psutil>=5.3.0 # BSD
pyroute2>=0.7.3;sys_platform!='win32' # Apache-2.0 (+ dual licensed GPL2)
pyOpenSSL>=17.1.0 # Apache-2.0
Fix issue with pip installing oslo.config-1.2.0 Fixes bug #1194807 Firstly, we update the oslo.config dep to 1.2.0a3 because of the issue with namespace packages (bug #1194742). But the main issue here is that if you currently do: $> pip install -r quantum/requirements.txt then you end up with the oslo.config 1.1.1 code installed. This is because oslo.config>=1.1.0 gets pulled in as a transitive dep and pip gets confused. You can reproduce with e.g. $> pip install \ http://.../oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2.0a3 \ python-keystoneclient $> pip freeze | grep oslo.config oslo.config-1.2.0a3 $> python -c 'from oslo.config.cfg import DeprecatedOpt' Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: cannot import name DeprecatedOpt This is because of a bug with pip where it sees oslo.config-1.2.0a3 and oslo.config as two unrelated things. It should strip the version part of the egg= fragment before using it as a package name, but it doesn't. However, we can simply use the -f/--find-links pip option in our requirements.txt to add the tarball URL to the list of URLs considered and also add the oslo.config>=1.2.0a3 dependency: $> pip install \ -f http://.../oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2.0a3 \ 'oslo.config>=1.2.0a3' \ python-keystoneclient $> pip freeze | grep oslo.config oslo.config-1.2.0a3 $> python -c 'from oslo.config.cfg import DeprecatedOpt' This is actually exactly the semantics we want and we go to great lengths in pbr to get these semantics while using a single tarball URL. The only downside to this --find-links strategy is that we gain an extra line in our requirements.txt ... but it does work around the pip bug. Change-Id: I6f3eb5fd2c75615d9a1cae172aed859b36b27d4c
2013-07-02 12:25:58 +01:00
python-novaclient>=9.1.0 # Apache-2.0
openstacksdk>=0.31.2 # Apache-2.0
python-designateclient>=2.7.0 # Apache-2.0
Avoid race condition when deleting trunk bridges Prior to this change, trunk bridges are created by os-vif but deleted by Neutron when the last vif is removed from it. This creates race conditions in some use cases, like DPDK with vhostuserclient mode, when VMs are rebooted. To avoid these races, Neutron will not delete trunk bridges anymore. Their creation and deletion will be os-vif's responsiblity. Since [1], Nova uses the os-vif version that contains this functionality. This patch also changes the trunk status change event. During a live migration, when the trunk parent port has been bound to the destination host (that means there is only one port binding associated) and the status has changed to ACTIVE, the method triggers the subport binding to the new host too. This is because there could be a race condition between the subport binding, triggered by the OVS agent, and the parent port binding, triggered by Nova. If when the OVS agent tries to bind the subports, the parent port is still bound to the source host, the subport binding remains in the source host too, instead of changing to the destination. This patch also reverts [2] and [3]. As commented in the previous paragraph, this patch fixes the issue reported in LP#1997025. The trunk port live migration with ML2/OVS must be fixed with this patch. [1]https://review.opendev.org/c/openstack/nova/+/865031 [2]https://review.opendev.org/c/openstack/neutron/+/865295 [3]https://review.opendev.org/c/openstack/neutron/+/865424 Closes-Bug: #1869244 Closes-Bug: #1997025 Change-Id: I4e16357f3ff214fcf41e418982806c24088a2665
2022-04-13 18:00:12 -05:00
os-vif>=3.1.0 # Apache-2.0
futurist>=1.2.0 # Apache-2.0
tooz>=1.58.0 # Apache-2.0
wmi>=1.4.9;sys_platform=='win32' # MIT