This trivial change ensures the instance is logged within the volume
drivers whenever possible to ease debugging.
Change-Id: Ib61ba7266ad58b311adcac566a96149839cb688e
The connection_info['data']['device_path'] field is not always
available. In cases that it was not available, it would cause
the debug code to raise a KeyError instead of proceeding.
Other similar debug messages in the same file do not include
device_path. As a simple fix, just drop the device_path from
the log.
Closes-Bug: #1936439
Change-Id: Id0539d2ee909d86ffef07ae566697db8ae0f83b4
Signed-off-by: Mark Mielke <mark.mielke@gmail.com>
Implement support for extending RBD attached volumes using the libvirt
network volume driver.
This adds a new parameter "requested_size" to the extend_volume method.
This is necessary because the new volume size can not be detected by
libvirt for network volumes. All other volume types currently
implementing the extend_volume call have a block device on the
hypervisor which needs to be updated and can be polled for it's new
size. For network volumes no such block device exists.
Alternatively this could be implemented without a new parameter by
calling into Ceph using os_brick to get the new size of the volume.
This would make the LibvirtNetVolumeDriver Ceph specific.
This also extends the logic to get the device_path for extending volumes
in the libvirt driver. This is necessary as network volumes don't have
the device path in the connection_info. The device_path is retrieved by
matching the connection_info serial (= volume UUID) against all guest
disks.
Co-Authored-By: Jose Castro Leon <jose.castro.leon@cern.ch>
Blueprint: extend-in-use-rbd-volumes
Change-Id: I5698e451861828a8b1240d046d1610d8d37ca5a2
_disconnect_volume was being passed disk_dev, which was is name of the
disk as presented to the gust. However, _disconnect_volume is only
concerned with unmounting the volume from the host, so this isn't
relevant.
A couple of volume drivers were using it for logging. We remove these
because it wasn't done consistently, is better done by the caller, and
isn't required as the information is available from other log
messages.
In the very minor associated debug log cleanup we also remove logging
of connection_info from one volume driver, which is potential security
bug.
We also do some associated cleanup in a few volume driver tests which
were assuming that disconnect_volume was being passed disk_info rather
than disk_dev, and that connection_info['data'] is related to
disk_info, which it isn't.
Change-Id: I61a0bee9e71e9a67f6a7c04a7bfd6e77fe818a77
_connect_volume was being passed disk_info as an argument. However,
the purpose of _connect_volume is to mount a volume on the compute
host, and disk_info only contains metadata about how the disk will be
presented to a guest. It's therefore not relevant, so it's not
surprising that no drivers are using it.
Change-Id: I843b5c46f9f93a30e7121259feff17a8170a2e48
Most drivers had hard coded protocol strings, and one driver was using
a constant from os-brick that has been deprecated for removal for quite
some time.
This updates all volume drivers to use the current available constants
from os-brick.
Change-Id: I8682804d2299db793c1e4397a07ff67608a8bda6
Closes-bug: #1721993
Allow Cinder to use external events to signal a volume extension.
1) Nova will then call os-brick to perform the volume extension
so the host can detect its new size.
2) Compute driver will resize the device in QEMU so instance can detect
the new disk size without rebooting.
This change:
* Adds the 'volume-extended' external event.
The event tag needs to be the extended volume id.
* Bumps the latest microversion to 2.51.
* Exposes non-traceback instance action event details for
non-admins on the microversion. This is needed for the
non-admin API user that initiated the volume extend
operation to be able to tell when the nova-compute side
is complete.
Co-Authored-By: Matt Riedemann <mriedem.os@gmail.com>
Blueprint: nova-support-attached-volume-extend
Change-Id: If10cffd0dc4c9879f6754ce39bee5fae1d04f474
The i18n team has decided not to translate the logs because it
seems like it not very useful; operators prefer to have them in
English so that they can search for those strings on the internet.
Partially fix on nova/virt other paths will be fixed on next commits
Change-Id: Ie7821aa4a5147cdb0616741bd1a1b1fc22080440
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.
We also add a utility test class: SubclassSignatureTestCase. This is
used in this patch to ensure we have found all connect_volume and
disconnect_volume methods which need to be updated. We implement it in
the top level tests module as we expect it to be useful elsewhere.
This patch was previously submitted as change I658d7ab5 but had to be
reverted as it failed to update the signatures of several volume
drivers. This is also what has prompted the addition of
SubclassSignatureTestCase, which ensures this hasn't happened again.
Change-Id: I01c908add1312063f0db724110f7e5927ff281ff
This reverts commit f0153fa4c8.
This broke a whole set of FS-based volume drivers since it
didn't change the method signatures in those drivers to take
the new instance argument.
I was working on adding them but then just decided this
isn't even used right now so it's faster to revert.
When this is added back in, I want to see the
LibvirtBaseVolumeDriver class turned into an ABC and
the connect_volume and disconnect_volume methods turned
into abstractmethods in LibvirtBaseVolumeDriver so this
kind of thing does not happen again.
Change-Id: If1ee6d6e4004750f80424ec54d7dabc564ec9e06
Closes-Bug: #1675584
* num_iscsi_scan_tries - was renamed to num_volume_scan_tries,
as the name was misleading. This opt was also moved to the list
that is more appropriate for it
Change-Id: Icb73ca7e3fcde1ef9b73d2238d8c986d109e459a
Implements: bp centralize-config-options-pike
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
We were initialising libvirt volume drivers by passing the
LibvirtDriver object. However, this is only ever used to fetch the
Host. We update the interface to pass the Host instead. This is
cleaner, but also better represents the intent of the interface. They
should not be able to access arbitrary attributes of the LibvirtDriver
object.
Change-Id: I87ceeee1ec46dc22754321574b16e6c47b27a848
This patch renames the libvirt conf section entry of
iscsi_use_multipath to volume_use_multipath. Both iSCSI and
FibreChannel libvirt volume drivers use this value to determine
if multipath volume attachments are to be used. It's an n-cpu system
wide value that's not specific to iSCSI.
Change-Id: Iebbac91a74df468d5be9b2e70560d5b4394ce595
Closes-Bug: #1593860
The config options of the "nova.conf" section "libvirt" got
moved to the new central location "nova/conf/libvirt.py".
Subsequent patches will then move another options in libvirt section.
This is the 10th patch in a long-chain patchs.
Change-Id: Iffd21940c8396460392e96e79d4ba98142fa39cc
Co-Authored-by: Markus Zoeller <mzoeller@de.ibm.com>
Implements: blueprint centralize-config-options-newton
If exceptions are raised, nova-compute can't start
when executing _destroy_evacuated_instances.
Change-Id: I0a2877ec0f922d2bc9a742d1c2c2540a6b77e9ce
Closes-Bug: #1532657
iscsi_use_multipath = False(BoolOpt) Use multipath connection of the
iSCSI volume
Above description is incorrect and misleading. Actually, this option
is applicable for both FC/iSCSI volumes
Change-Id: Ifdc6a2935702311eb8af363c742b5ab44c7a0d0f
DocImpact: Change the config description of iscsi_use_multipath
Closes-bug: #1495876
The nova.utils._get_root_helper() method is used outside of the
nova.utils module, so we should make it public.
Change the method to nova.utils.get_root_helper()
Change-Id: I63273aa3115502d2cd049c99b2176a7eca0d2f4c
Closes-Bug: #1479345
Removes some unused methods in the tests and adds a couple of
TODO comments on moving tests into os-brick which were missed
during the review of commit e6cdd1693b.
Part of blueprint consolidate-libvirt-fs-volume-drivers
Change-Id: I64901b1456a3989c3ee700f1da6d47f47f2734bb
Lee Yarwood
Mark Mielke
Gaudenz Steinlin
Matthew Booth
Sean McGinnis
Mathieu Gagné
Ngo Quoc Cuong
Matt Riedemann
Maciej Szankin
Walter A. Boring IV
Hieu LE
maqi
Alexander Schmidt
Shuquan Huang
Takashi NATSUME
Matt Riedemann