cbf6a46d8f
By the time finish_resize runs on the dest host, the instance
host/node values are already pointing at the dest (they are
set by resize_instance on the source compute before casting to
finish_resize on the dest). If finish_resize fails, the instance
is essentially stuck on the dest host so rather than revert the
allocations (which will drop the new flavor allocations against
the dest host where the instance now lives) we should just drop
the old flavor allocations on the source node resource provider,
which is what this change does.
The functional regression recreate test is updated to show this
working.
Conflicts:
nova/tests/functional/regressions/test_bug_1825537.py
nova/tests/functional/test_servers.py
NOTE(mriedem): The functional test conflicts are due to not having
change If6aa37d9b6b48791e070799ab026c816fda4441c in Rocky.
The code fix is also different because we don't have change
I0851e2d54a1fdc82fe3291fb7e286e790f121e92 in Rocky and cannot use
the _delete_allocation_after_move method as documented inline.
This also means we have to deal with migration-based and legacy
tracked allocations (where the source and dest node allocations
are both on the instance consumer). As such, similar logic to
_delete_allocation_after_move is used to try and delete the
migration-based allocations first and failing that, attempt
to cleanup the source node allocations the legacy way by removing
them from the "doubled up" allocations created by the scheduler.
Since this is new logic in the backport, a functional test is
added to cover the legacy cleanup flow.
Change-Id: I52c8d038118c858004e17e71b2fba9e9e2714815
Closes-Bug: #1825537
(cherry picked from commit
|
||
|---|---|---|
| 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 | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| MAINTAINERS | ||
| README.rst | ||
| babel.cfg | ||
| bindep.txt | ||
| lower-constraints.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: