26da4418a9
When reverting a cross-cell resize, conductor will: 1. clean up the destination host 2. set instance.hidden=True and destroy the instance in the target cell database 3. finish the revert on the source host which will revert the allocations on the source host held by the migration record so the instance will hold those again and drop the allocations against the dest host which were held by the instance. If the ResourceTracker.update_available_resource periodic task runs between steps 2 and 3 it could see that the instance is deleted from the target cell but there are still allocations held by it and delete them. Step 3 is what handles deleting those allocations for the destination node, so we want to leave it that way and take the ResourceTracker out of the flow. This change simply checks the instance.hidden value on the deleted instance and if hidden=True, assumes the allocations will be cleaned up elsehwere (finish_revert_snapshot_based_resize_at_source). Ultimately this is probably not something we *have* to have since finish_revert_snapshot_based_resize_at_source is going to drop the destination node allocations anyway, but it is good to keep clear which actor is doing what in this process. Part of blueprint cross-cell-resize Change-Id: Idb82b056c39fd167864cadd205d624cb87cbe9cb |
||
|---|---|---|
| api-guide/source | ||
| api-ref/source | ||
| devstack | ||
| doc | ||
| etc/nova | ||
| gate | ||
| nova | ||
| playbooks | ||
| releasenotes | ||
| roles/run-post-test-hook | ||
| tools | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .pre-commit-config.yaml | ||
| .stestr.conf | ||
| .zuul.yaml | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| MAINTAINERS | ||
| README.rst | ||
| babel.cfg | ||
| bindep.txt | ||
| lower-constraints.txt | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
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: