2b5fe5db0d
There is a race during allocate_fixed_ip where a new instance, B, is
associated with a fixed IP, X, which was previously associated with
instance A that is being deallocated.
Between the time that instance A is associated with fixed IP X and the
time that it's VIF is allocated, and fip.allocated = True in the DB, the
dhcpagent callback hits release_fixed_ip for the fixed IP X from when
instance A was deallocating.
release_fixed_ip checks to see if the instance is allocated and if not
it disassociates the instance, which was associated with new instance B.
This leads to get_instance_nw_info() not building anything since there
are no fixed IPs associated with instance A in the database, so
eventually anything needing to do networking with instance A, like
assocating a floating IP, fails.
To narrow the race, we do the VIF allocation before associating the
fixed IP to the new instance. This does not completely fix the bug, but
it's a tactical change that we can backport to stable branches while
working on the longer-term fix which is going to involve network RPC API
changes to release_fixed_ip().
Note that test_vpn_allocate_fixed_ip_no_network_id is removed since it
no longer works and arguably was testing the DB API in the wrong place,
so a new test is added to test_db_api for the same coverage.
Partial-Bug: #1249065
Change-Id: I8cf5483982085da57ee470fa2753b0d0aebc12b3
(cherry picked from commit
|
||
|---|---|---|
| contrib | ||
| doc | ||
| etc/nova | ||
| nova | ||
| plugins/xenserver | ||
| tools | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .testr.conf | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| MANIFEST.in | ||
| README.rst | ||
| babel.cfg | ||
| openstack-common.conf | ||
| requirements.txt | ||
| run_tests.sh | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
OpenStack Nova README
OpenStack Nova provides a cloud computing fabric controller, supporting a wide variety of virtualization technologies, including KVM, Xen, LXC, VMware, and more. In addition to its native API, it includes compatibility with the commonly encountered Amazon EC2 and S3 APIs.
OpenStack Nova is distributed under the terms of the Apache License, Version 2.0. The full terms and conditions of this license are detailed in the LICENSE file.
Nova primarily consists of a set of Python daemons, though it requires and integrates with a number of native system components for databases, messaging and virtualization capabilities.
To keep updated with new developments in the OpenStack project follow @openstack on Twitter.
To learn how to deploy OpenStack Nova, consult the documentation available online at:
For information about the different compute (hypervisor) drivers supported by Nova, read this page on the wiki:
In the unfortunate event that bugs are discovered, they should be reported to the appropriate bug tracker. If you obtained the software from a 3rd party operating system vendor, it is often wise to use their own bug tracker for reporting problems. In all other cases use the master OpenStack bug tracker, available at:
Developers wishing to work on the OpenStack Nova project should always base their work on the latest Nova code, available from the master GIT repository at:
Developers should also join the discussion on the mailing list, at:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Any new code must follow the development guidelines detailed in the HACKING.rst file, and pass all unit tests. Further developer focused documentation is available at:
For information on how to contribute to Nova, please see the contents of the CONTRIBUTING.rst file.
-- End of broadcast