245364ece1
When we shelve offload an instance, we unplug VIFs, delete the guest from the compute host, etc. The instance is still logically attached to its ports but they aren't connected on any host. When we unshelve an instance, it is scheduled and created on a potentially new host, in a potentially new availability zone. During unshelve, the compute manager will call the setup_instance_network_on_host() method to update the port host binding information for the new host, but was not updating the device_owner, which reflects the availability zone that the instance is in. Because of this, an instance can be created in az1, shelved, and then unshelved in az2 but the port device_owner still says az1 even though the port host binding is for a compute host in az2. This change simply updates the port device_owner when updating the port binding host during unshelve. A TODO is left in the cleanup_instance_network_on_host() method which is called during shelve offload but is currently not implemented. We should unbind ports when shelve offloading, but that is a bit of a bigger change and left for a separate patch since it is not technically needed for this bug fix. Change-Id: Ibd1cbe0e9b5cf3ede542dbf62b1a7d503ba7ea06 Closes-Bug: #1759924 (cherry picked from commit |
||
|---|---|---|
| api-guide/source | ||
| api-ref/source | ||
| contrib | ||
| devstack | ||
| doc | ||
| etc/nova | ||
| gate | ||
| nova | ||
| placement-api-ref/source | ||
| playbooks/legacy | ||
| releasenotes | ||
| tools | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .stestr.conf | ||
| .zuul.yaml | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| MAINTAINERS | ||
| README.rst | ||
| babel.cfg | ||
| bindep.txt | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tests-py3.txt | ||
| tox.ini | ||
README.rst
Team and repository tags
OpenStack Nova
OpenStack Nova provides a cloud computing fabric controller, supporting a wide variety of compute technologies, including: libvirt (KVM, Xen, LXC and more), Hyper-V, VMware, XenServer, OpenStack Ironic and PowerVM.
Use the following resources to learn more.
API
To learn how to use Nova's API, consult the documentation available online at:
For more information on OpenStack APIs, SDKs and CLIs in general, refer to:
Operators
To learn how to deploy and configure OpenStack Nova, consult the documentation available online at:
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
For information on how to contribute to Nova, please see the contents of the CONTRIBUTING.rst.
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:
Other Information
During each Summit and Project Team Gathering, we agree on what the whole community wants to focus on for the upcoming release. The plans for nova can be found at: