37301f2f27
This patch adds the handling of consumer generation conflict for the scheduler report client claim_resources function. Note that almost every instance move operation uses the migration.uuid to hold the source node allocation while attempting to allocate on the destination for the instance. The only exception is evacuation as during evacuation both the source and the destination allocations are held by the instance.uuid as consumer. There are three major cases handled regarding consumer generation conflicts during claim_resources: * The caller wants to claim resources and assumes that the provided consumer is a new consumer. For example scheduler claims during the build of a new instance or during the move of an existing instance and the source allocation is held by the migration_uuid. In this case if Placement returns consumer generation conflict then there is a serious inconsistency about that consumer. So this patch ensures that the operation is aborted. * The caller knows that there is allocation on the consumer before calling claim and reads the current allocation from Placement. The only example of this in the current codebase is forced evacuation. In this case the caller provides the consumer_generation to claim_resources. If Placement returns consumer generaton conflict then the caller aborts the operation. * The scheduler wants to claim resources for a non-forced evacuation. The scheduler does not know that it is an evacuate operation and the scheduler only sees allocation candidates. Therefore the scheduler uses the same code path as in the first case and calls claim_resources without providing consumer generation. In this case the claim_resources code needs to read the actual consumer generation from Placement. If during this claim Placement returns consumer generaton conflict then claim_resource will raise and let the caller abort the opertion. Blueprint: use-nested-allocation-candidates Change-Id: I097732754b67bd5cf50abd15db7da3f013b6cdd5 |
||
|---|---|---|
| api-guide/source | ||
| api-ref/source | ||
| contrib | ||
| devstack | ||
| doc | ||
| etc/nova | ||
| gate | ||
| nova | ||
| placement-api-ref | ||
| playbooks/legacy | ||
| releasenotes | ||
| tools | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .stestr.conf | ||
| .zuul.yaml | ||
| babel.cfg | ||
| bindep.txt | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| lower-constraints.txt | ||
| MAINTAINERS | ||
| README.rst | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
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: