When creating a network and adding a port, the API requests will often be handled by different workers. Since each worker maintains its own internal copy of the OVN DBs, it is possible that the request for creating the port arrives at a worker that has not yet received notification that the Logical Switch for the network has been created. When the code for adding the Logical Switch Port is called, it tries to look up the LS, and fails. Currently, a retry-and-wait solution is in place for the LS/LSP issue in create_port(), but a new feature introduced in OVS 3.1 allows specifying the UUID of the LS, so that we can use a value known to the other worker, and add the LSP to the LS by that UUID even if the LS isn't in our local DB cache. This allows the ovsdb-server to be the source of truth on the existance of the LS. There are lots of other interactions that could result in this kind of race condition, any create/update of objects that happen rapidly on systems under high load for example. This method of creating and referencing objects should be generalizable. In this patch, the UUID for the LS is defined as the UUID for the neutron network. The name of the LS continues to be neutron-$UUID to match existing usage and to keep lookups by name working. Change-Id: Icc27c2b8825d7f96c9dac87dec8bbb55d493d942
59 lines
1.8 KiB
Plaintext
59 lines
1.8 KiB
Plaintext
# 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.
|
|
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.36.1 # MIT
|
|
pecan>=1.4.0 # BSD
|
|
httplib2>=0.22.0 # MIT
|
|
requests>=2.32.3 # Apache-2.0
|
|
Jinja2>=2.10 # BSD License (3 clause)
|
|
keystonemiddleware>=5.1.0 # Apache-2.0
|
|
netaddr>=0.7.18 # BSD
|
|
neutron-lib>=3.17.0 # 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.4.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>=5.3.0 # Apache-2.0
|
|
oslo.messaging>=7.0.0 # Apache-2.0
|
|
oslo.middleware>=3.31.0 # Apache-2.0
|
|
oslo.policy>=4.5.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>=5.5.0 # Apache-2.0
|
|
oslo.service>=3.5.0 # Apache-2.0
|
|
oslo.upgradecheck>=1.3.0 # Apache-2.0
|
|
oslo.utils>=7.3.0 # Apache-2.0
|
|
oslo.versionedobjects>=1.35.1 # Apache-2.0
|
|
osprofiler>=2.3.0 # Apache-2.0
|
|
os-ken>=3.0.0 # Apache-2.0
|
|
os-resource-classes>=1.1.0 # Apache-2.0
|
|
ovs>3.3.0 # Apache-2.0
|
|
ovsdbapp>=2.11.0 # Apache-2.0
|
|
psutil>=6.1.0 # BSD
|
|
pyroute2>=0.7.3;sys_platform!='win32' # Apache-2.0 (+ dual licensed GPL2)
|
|
pyOpenSSL>=17.1.0 # Apache-2.0
|
|
|
|
python-novaclient>=9.1.0 # Apache-2.0
|
|
openstacksdk>=0.31.2 # Apache-2.0
|
|
python-designateclient>=2.7.0 # Apache-2.0
|
|
os-vif>=3.1.0 # Apache-2.0
|
|
futurist>=1.2.0 # Apache-2.0
|
|
tooz>=1.58.0 # Apache-2.0
|