8f1773a7af
Change Ic3968721d257a167f3f946e5387cd227a7eeec6c in Newton
started setting the RequestSpec.ignore_hosts field to the
source instance.host during resize/cold migrate if
allow_resize_to_same_host=False in config, which it is by
default.
Change I8abdf58a6537dd5e15a012ea37a7b48abd726579 also in
Newton persists changes to the RequestSpec in conductor
in order to save the RequestSpec.flavor for the new flavor.
This inadvertently persists the ignore_hosts field as well.
Later if you try to evacuate or unshelve the server it will ignore
the original source host because of the persisted ignore_hosts
value. This is obviously a problem in a small deployment with only
a few compute nodes (like an edge deployment). As a result, an
evacuation can fail if the only available host is the one being
ignored.
This change does two things:
1. In order to deal with existing corrupted RequestSpecs in the DB,
this change simply makes conductor overwrite RequestSpec.ignore_hosts
rather than append during evacuate before calling the scheduler so
the current instance host (which is down) is filtered out.
This evacuate code dealing with ignore_hosts goes back to Mitaka:
I7fe694175bb47f53d281bd62ac200f1c8416682b
The test_rebuild_instance_with_request_spec unit test is updated
and renamed to actually be doing an evacuate which is what it was
intended for, i.e. the host would not change during rebuild.
2. This change makes the RequestSpec no longer persist the ignore_hosts
field like several other per-operation fields in the RequestSpec.
The only operations that use ignore_hosts are resize (if
allow_resize_to_same_host=False), evacuate and live migration, and
the field gets reset in each case to ignore the source instance.host.
The related functional recreate test is also updated to show the
bug is fixed. Note that as part of that, the confirm_migration method
in the fake virt driver needed to be implemented otherwise trying to
evacuate back to the source host fails with an InstanceExists error since
the confirmResize operation did not remove the guest from the source host.
Conflicts:
nova/objects/request_spec.py
nova/tests/unit/conductor/test_conductor.py
nova/tests/unit/objects/test_request_spec.py
NOTE(mriedem): The (test_)request_spec.py conflicts are due to not
having change I2131558f0edfe603ee1e8d8bae66a3caf5182a58 in Queens.
test_save_does_not_persist_requested_fields from that change is
ported and modified here to just deal with the ignore_hosts field.
The test_conductor.py conflict is due to not having change
I640562b8dd049ff5b6fea9286dc3082b9d837ed3 in Queens.
Change-Id: I3f488be6f3c399f23ccf2b9ee0d76cd000da0e3e
Closes-Bug: #1669054
(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: