4aa39c44a4
A single nfs export typically contains multiple volumes. We were handling this in the libvirt driver by: 1. On mount, we 'ensure' the mount is available, so we don't fail if another instance already has it mounted. 2. On umount, we trap and ignore 'device is busy' so we don't fail if another instance is already using it. Unfortunately, while this works for serial mounts and unmounts, there are multiple failure cases when volumes from the same export are mounted and unmounted simultaneously. It causes an error if an instance is stopped: as the qemu process is not actively using the mountpoint it will not prevent an unmount for another volume on the same mountpoint from succeeding. It will not be possible to restart the instance, because its mountpoint will not be mounted. To fix this, we create a singleton manager object, which tracks mounts and umount requests per export, and calls the real mount/umount only when required. It uses per-export locks to allow concurrency while avoiding races. Because we now expect to know the state of the host at all times, we no longer need to execute speculative mount/umount commands. As we track attachments (a mapping from volume to instance) rather than volumes, we also gracefully support multi-attach. This change implements this for nfs, but the solution is intended to be extended to all LibvirtBaseFileSystemVolumeDrivers. Closes-Bug: #1421550 Change-Id: I3155984d76df06371a6c45f633aa448168a96d64 |
||
---|---|---|
api-guide/source | ||
api-ref/source | ||
contrib | ||
devstack | ||
doc | ||
etc/nova | ||
gate | ||
nova | ||
placement-api-ref/source | ||
plugins/xenserver | ||
releasenotes | ||
tools | ||
.coveragerc | ||
.gitignore | ||
.gitreview | ||
.mailmap | ||
.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 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:
https://developer.openstack.org/api-guide/compute/ https://developer.openstack.org/api-ref/compute/
For more information on OpenStack APIs, SDKs and CLIs, please see:
https://www.openstack.org/appdev/ https://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:
https://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: