3f8daf0804
We call _hard_reboot during reboot, power_on, and resume_state_on_host_boot. It functions essentially by tearing as much of an instance as possible before recreating it, which additionally makes it useful to operators for attempting automated recovery of instances in an inconsistent state. The Libvirt driver would previously only call _destroy and _undefine_domain when hard rebooting an instance. This would leave vifs plugged, volumes connected, and encryptors attached on the host. It also means that when we try to restart the instance, we assume all these things are correctly configured. If they are not, the instance may fail to start at all, or may be incorrectly configured when starting. For example, consider an instance with an encrypted volume after a compute host reboot. When we attempt to start the instance, power_on will call _hard_reboot. The volume will be coincidentally re-attached as a side-effect of calling _get_guest_xml(!), but when we call _create_domain_and_network we pass reboot=True, which tells it not to reattach the encryptor, as it is assumed to be already attached. We are therefore left presenting the encrypted volume data directly to the instance without decryption. The approach in this patch is to ensure we recreate the instance as fully as possible during hard reboot. This means not passing vifs_already_plugged and reboot to _create_domain_and_network, which in turn requires that we fully destroy the instance first. This addresses the specific problem given in the example, but also a whole class of potential volume and vif related issues of inconsistent state. Because we now always tear down volumes, encryptors, and vifs, we are relying on the tear down of these things to be idempotent. This highlighted that detach of the luks and cryptsetup encryptors were not idempotent. We depend on the fixes for those os-brick drivers. Depends-On: I31d72357c89db53a147c2d986a28c9c6870efad0 Depends-On: I9f52f89b8466d03699cfd5c0e32c672c934cd6fb Closes-bug: #1724573 Change-Id: Id188d48609f3d22d14e16c7f6114291d547a8986 |
||
|---|---|---|
| api-guide/source | ||
| api-ref/source | ||
| contrib | ||
| devstack | ||
| doc | ||
| etc/nova | ||
| gate | ||
| nova | ||
| placement-api-ref/source | ||
| releasenotes | ||
| tools | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .stestr.conf | ||
| .testr.conf | ||
| CONTRIBUTING.rst | ||
| HACKING.rst | ||
| LICENSE | ||
| MAINTAINERS | ||
| README.rst | ||
| babel.cfg | ||
| bindep.txt | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tests-functional-py3.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: