03999961ac
We've had a series of bugs with resources that need to be unique on the system across test runner processes. Ports are used by neutron-server and the OVS agent when run in native openflow mode. The function that generates ports looks up random unused ports and starts the service. However, it is raceful: By the time the port is found to be unused and the service is started, another test runner can pick the same random port. With close to 65536 ports to choose from, the chance for collision is low, but given enough test runs, it's happened a non-trivial amount of times, and given that a voting job needs a very low false-negative rate, we need a more robust solution. The same applies to IP addresses that are used by the OVS agent in tunneling mode, and for the LB agent in all modes. With IP addresses, we don't check if the IP address is used, we simply pick a random address from a large pool, and again we've seen a non-trivial amount of test failures. The bugs referenced below had simple, short term solutions applied but the bugs remain remain. This patch is a correct, long term solution that doesn't rely on chance. This patch adds a resource allocator that uses the disk to persist allocations. Access to the disk is guarded via a file lock. IP address, networks and ports fixtures use an allocator internally. Closes-Bug: #1551288 Closes-Bug: #1561248 Closes-Bug: #1560277 Change-Id: I46c0ca138b806759128462f8d44a5fab96a106d3 |
||
|---|---|---|
| bin | ||
| devstack | ||
| doc | ||
| etc | ||
| neutron | ||
| rally-jobs | ||
| releasenotes | ||
| tools | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .pylintrc | ||
| .testr.conf | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| MANIFEST.in | ||
| README.rst | ||
| TESTING.rst | ||
| babel.cfg | ||
| openstack-common.conf | ||
| requirements.txt | ||
| run_tests.sh | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
Welcome!
You have come across a cloud computing network fabric controller. It has identified itself as "Neutron." It aims to tame your (cloud) networking!
External Resources:
The homepage for Neutron is: http://launchpad.net/neutron. Use this site for asking for help, and filing bugs. Code is available on git.openstack.org at <http://git.openstack.org/cgit/openstack/neutron>.
The latest and most in-depth documentation on how to use Neutron is available at: <http://docs.openstack.org>. This includes:
- Neutron Administrator Guide
- Networking Guide
- Neutron API Reference:
-
http://docs.openstack.org/api/openstack-network/2.0/content/
- Current Neutron developer documentation is available at:
For help on usage and hacking of Neutron, please send mail to <mailto:openstack-dev@lists.openstack.org>.
For information on how to contribute to Neutron, please see the contents of the CONTRIBUTING.rst file.