ede6db6c4c
When processing port events (create, update, delete), the port provisioning (port creation) has priority over the other events [1]. As reported in the related bug, if a port deletion with an IP address and another port creation with the same IP address arrive to the DHCP agent, those events can be processed in the same queue. Because of the creation event priority, even when this event arrived after the deletion event, it will be processed first. That will clash with the DHCP agent cache, that contains a port (not deleted yet) with the same IP address. That will trigger an unwanted resync. This patch implements a specific logic to store the events in "ResourceProcessingQueue" (that uses "PriorityQueue" [2]). When a port event arrives, the event comparison method checks the (subnet, fixed_ips) tuple set of both elements. If there is a coincidence, that means those ports are the same or are using the same IP addreses (the race condition explained in the bug). In this case, the priority is defined only by the timestamp; that means the events are processed in order of arrival. Because the Neutron server do not allow to have two ports in the same subnet with the same IP address, the order of the events is guaranteed. In the case explained in the bug, the deletion event will be processed first. [1]https://review.opendev.org/c/openstack/neutron/+/626830 [2]https://docs.python.org/3/library/queue.html#queue.PriorityQueue Closes-Bug: #1913723 Change-Id: I89438feae3c0244f6da5e6a2a035d45b956ac247 |
||
---|---|---|
api-ref | ||
devstack | ||
doc | ||
etc | ||
neutron | ||
playbooks | ||
rally-jobs | ||
releasenotes | ||
roles | ||
tools | ||
vagrant/ovn | ||
zuul.d | ||
.coveragerc | ||
.gitignore | ||
.gitreview | ||
.mailmap | ||
.pylintrc | ||
.stestr.conf | ||
CONTRIBUTING.rst | ||
HACKING.rst | ||
LICENSE | ||
README.rst | ||
TESTING.rst | ||
bindep.txt | ||
plugin.spec | ||
requirements.txt | ||
setup.cfg | ||
setup.py | ||
test-requirements.txt | ||
tox.ini |
README.rst
OpenStack Neutron
Neutron is an OpenStack project to provide "network connectivity as a service" between interface devices (e.g., vNICs) managed by other OpenStack services (e.g., Nova).
To learn more about neutron:
- Documentation: https://docs.openstack.org/neutron/latest/
- Features: https://specs.openstack.org/openstack/neutron-specs
- Defects: https://launchpad.net/neutron
- Release notes: https://docs.openstack.org/releasenotes/neutron/index.html
- Source: https://opendev.org/openstack/neutron
Get in touch via email. Use [Neutron] in your subject.
To learn how to contribute, please read the CONTRIBUTING.rst file.