f0153fa4c8
When we support multi-attach volumes, for volume drivers which must make host state changes (eg mount/unmount) it is no longer enough to know only which volume is being connected; we must also know which instance it is being attached to. Consider the following sequence of calls, and the expected behaviour of the volume driver: * connect_volume(conn_info) connect the volume * connect_volume(conn_info) do nothing (volume is already connected) * disconnect_volume(conn_info) disconnect the volume * disconnect_volume(conn_info) do nothing (volume is already disconnected) Now consider these were actually connections to different instances: * connect_volume(conn_info, A) connect the volume * connect_volume(conn_info, B) do nothing (volume is already connected) * disconnect_volume(conn_info, A) ++ do nothing (volume is still connected to B) * disconnect_volume(conn_info, B) disconnect the volume IOW, it is not possible for the driver to determine the correct behaviour unless it also knows which instance is being attached. This is a non functional change which simply adds instance as an argument to all connect_volume and disconnect_volume calls in libvirt volume drivers. It is effectively a part of change I3155984d. I have split it as it is mechanical, it touches a large number of files which make the substantive change harder to read, and to isolate the substantive change from merge conflicts caused by this change. Change-Id: I658d7ab503cb17ae6750fd301d49e2c46085a0c0 |
||
---|---|---|
api-guide/source | ||
api-ref/source | ||
contrib | ||
devstack | ||
doc | ||
etc/nova | ||
gate | ||
nova | ||
plugins/xenserver | ||
releasenotes | ||
tools | ||
.coveragerc | ||
.gitignore | ||
.gitreview | ||
.mailmap | ||
.testr.conf | ||
babel.cfg | ||
bindep.txt | ||
CONTRIBUTING.rst | ||
HACKING.rst | ||
LICENSE | ||
MAINTAINERS | ||
README.rst | ||
requirements.txt | ||
run_tests.sh | ||
setup.cfg | ||
setup.py | ||
test-requirements.txt | ||
tests-functional-py3.txt | ||
tests-py3.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 and OpenStack Ironic.
OpenStack Nova is distributed under the terms of the Apache License, Version 2.0. The full terms and conditions of this license are detailed in the LICENSE file.
API
To learn how to use Nova's API, consult the documentation available online at:
http://developer.openstack.org/api-guide/compute/ http://developer.openstack.org/api-ref/compute/
For more information on OpenStack APIs, SDKs and CLIs, please see:
http://www.openstack.org/appdev/ http://developer.openstack.org/
Operators
To learn how to deploy and configure OpenStack Nova, consult the documentation available online at:
For information about the different compute (hypervisor) drivers supported by Nova, please read:
http://docs.openstack.org/developer/nova/feature_classification.html
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: