This enables use of ephemeral encryption for swap disks.
The 'encrypted' attribute is intended to be read-only, so we will raise
an error if something attempts to save it later.
DriverImageBlockDevice and DriverEphemeralBlockDevice are already not
saving updates to their 'encrypted' attributes, so the same error
checking is added to them as well for consistency.
Related to blueprint ephemeral-encryption-libvirt
Change-Id: Id30577699928180eff6a5b78390ce9e3efa28b16
Bug #1937084 details a race condition within Cinder where requests to
delete an attachment and later delete the underlying volume can race
leading to the initial request returning a 404 if the volume delete
completes first.
This change attempts to handle this within Nova during a detach as we
ultimately don't care that the volume and/or volume attachment are no
longer available within Cinder. This allows Nova to complete its' own
cleanup of the BlockDeviceMapping record resulting in the volume no
longer appearing attached in Nova's APIs.
Closes-Bug: #1937084
Change-Id: I191552652d8ff5206abad7558c99bce27979dc84
A future change will bump flake8 to 3.x. See off most of the issues that
this will introduce now, with the exception of some missing typing
imports in 'nova/virt/hardware.py' - fixing those here with the current
version of flake8 would actually raise an error about unused imports.
Change-Id: I9480ac1749d448efe4f415f5e80ff9b9837216b6
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
Attempts to launch an instance from an encrypted volume snapshot would
previously fail if a volume_type was not specified in the
block_device_mapping of the boot request.
To avoid such failures DriverVolSnapshotBlockDevice will now attempt to
lookup and use the volume_type of the original volume that the snapshot
is based on. This should allow the eventual volume creation request
based on the snapshot to succeed in cases where a volume_type is
required but not provided in the boot request.
Closes-Bug: #1853495
Change-Id: Ic749c49e227e41732dbe04acea303b303acd264a
When performing a boot from volume with an existing volume the compute
API creates a volume attachment for the BDM so that we do a new-style
attach flow in DriverVolumeBlockDevice.attach.
However, when booting from source_type of blank, image or snapshot, where
nova-compute creates the volume and then attaches it, we were still doing
the legacy attach flow because there was no attachment_id on the BDM.
This change fixes that so when nova creates the volume we also create the
volume attachment so we can go down the new style attach flow. Note that
we unconditionally create the volume attachment record since we require
Cinder Queens since Nova Train [1][2].
This is important for eventually migrating off the old attach flow so we
can drop that code. In other words, doing this means we eventually have
fewer data records to migrate before we can drop the compat code.
[1] I6a777b4b7a5729488f939df8c40e49bd40aec3dd
[2] Ic9d1fb364e06e08250c7c5d7d4bdb956cb60e678
Change-Id: I30a49c9e085cffc071d0ba332db67945e116bc80
Closes-Bug: #1747693
This centralizes the code that creates a volume during
boot from volume and the BDM source_type is one of blank,
image or snapshot.
In a subsequent change [1] the central _create_volume method
will be enhanced to create a "new style" volume attachment.
[1] I30a49c9e085cffc071d0ba332db67945e116bc80
Change-Id: I4205c00311f389907dcc390869414687ac03b7f5
Related-Bug: #1747693
Cinder introduced "shared_targets" and "service_uuid" fields in volumes
to allow volume consumers to protect themselves from unintended leftover
devices when handling iSCSI connections with shared targets.
Nova avoids races caused by automatic rescans on iSCSI volumes when
detaching a volume while Cinder is mapping another volume to the same
host by locking and only allowing one attach or one detach operation for
each server to happen at a given time if "shared_targets" is set to
True.
When using an up to date Open iSCSI initiator we don't need to use
locks, as it is possible to disable automatic LUN scans (which are the
real cause of the leftover devices), and OS-Brick already supports this
feature.
Currently Nova is blindly locking whenever "shared_targets" is set to
True, even when the iSCSI initiator and OS-Brick are already presenting
such races, which introduces unnecessary locking and serialization on
the connection of volumes.
This patch uses the new context manager introduced in OS-Brick to allow
Nova to abstract its code from all this storage internal details and to
only lock when it's really necessary.
Depends-On: I4970363301d5d1f4e7d0f07e09b34d15ee6884c3
Closes-Bug: #1800515
Change-Id: Ie9106d5832d6a728ea97a8dbb5ddb5dcc17a2ec4
There are several code paths which expect connection_info to be
a valid JSON object. However, if we don't find a value, we are
setting it to an initial value of 'None' which evenutally gets
converted to 'null' as JSON and stored in the database.
This patch sets the default value to {} so that any new block
device mappings have an empty object, rather than NULL.
Closes-Bug: #1821244
Change-Id: I15a7c13edf78884ec223fd531a78a341106b41b8
The following methods are overridden in DriverBlockDevice class.
* __getattr__
* __getitem__
The 'get' method is not overridden.
The value cannot be got by the 'get' method
though the value can be got by '__getattr__' (e.g. bdm.volumd_id)
or '__getitem__' (e.g. bdm['volume_id']) method.
So override the 'get' method to fix the issue.
Change-Id: Ic665fc1956831110937d98553e526cb909e49997
Closes-Bug: #1816938
Add support specifying ``volume_type`` to storage backend
when booting instance in compute version 36.
bp: boot-instance-specific-storage-backend
Change-Id: Icc301230fe7c8e3ebbbcc7f4a807e562db7f93e3
The call to os-roll_detaching was dropped when
I3800b466a50b1e5f5d1e8c8a963d9a6258af67ee started to catch and reraise
DeviceDetachFailed. This call is required to ensure a volume returns to
an in-use state when the instance is unable to detach.
Closes-Bug: #1786318
Change-Id: I6b3dc09acc6f360806ce0ef8c8a65addbf4a8c51
Currently only _proxy_as_attr fields are available as attributes, and
they are not available as dict values. Other values are available as
both. This is inconsistent. This change ensures all fields are exposed
as both dict values and attributes, so the caller doesn't have to
remember which type of attribute they're accessing.
Part of bp local-disk-serial-numbers
Change-Id: I35ebff9a06617aa58e612919eba81e8eea21f6a3
Change I751fcb7532679905c4279744919c6cce84a11eb4 modified
the ComputeDriver.detach_volume method signature to pass
the RequestContext as the first argument. This was missed
in the volume attach rollback code where the driver.detach_volume
method is called. It was missed because that is called
in a try/except block which catches generic Exception, which
also means that the unit test covering that flow, which
raised an Exception, was not failing.
This change fixes the code bug and re-writes the test to
use mock rather than mox and explicitly assert the calls made.
An alternative to this would be changing the generic
Exception handling in the rollback code, however, the
virt drivers raise things other than NovaException, like
os-brick exceptions and libvirtError, so refactoring that
error handling is non-trivial.
Change-Id: I9bafd4c47489b61973302310720b11ec1b5e0374
Closes-Bug: #1765742
To resolve this TODO in the ironic virt driver [1], and because the
PowerVM driver is facing similar difficulties [2], this change proxies
the is_volume @property from BlockDeviceMapping through
DriverBlockDevice and thus its inheritors, including
DriverVolumeBlockDevice, which is what a bdm actually seems to be by the
time it gets to a virt driver.
[1] 1605391084/nova/virt/ironic/driver.py (L392-L397)
[2] https://review.openstack.org/#/c/526094/45/nova/virt/powervm/driver.py@559
Change-Id: I3976a9305e0583ee77295df3636926688a1ca4ce
This makes the code slightly easier to understand, for example because
it's more obvious that DriverVolImageBlockDevice is a volume. It will
also be less confusing when we add DriverLocalImageBlockDevice in a
future patch.
Rename things in test_block_device for the same reasons.
Part of bp local-disk-serial-numbers
Change-Id: I5aa41a675d79945df6293f46eeb1a2fcc67241fb
When we attach a multiattach-capable volume, we do something
dirty and stash a "multiattach" boolean flag in the
BlockDeviceMapping.connection_info dict. This is used by the
virt driver to determine how to connect the volume (for the
libvirt driver, it sets the "shareable" element on the disk
config xml).
When resizing an instance, ComputeManager._finish_resize on
the destination host refreshes the block device mapping list
along with the connection_info for each BDM. Because of this,
it would overwrite the BDM.connection_info along with the stashed
"multiattach" flag which is later used to connect the volumes
on the destination host via the virt driver.finish_migration
method. This leads to failures with multiattach volumes because
the disk config is wrong.
To fix this, when refreshing BDM connection_info, we preserve
the multiattach flag in the connection_info, similar to the
serial (volume ID) and multipath_id.
Interestingly enough, the nova-multiattach job does not fail
the volume multiattach resize test with libvirt 1.3.1 and qemu
2.5. This failure was only noticed once the nova-multiattach
job was tested with libvirt 4.0.0 and qemu 2.11.1. So maybe there
was something in the older package versions that masked this
obvious bug in the nova code.
Change-Id: Iaee13478212cc04e6d1a1249f33822369d94d41d
Closes-Bug: #1757190
We need this in a later change to pull volume attachment
information from cinder for the volume being detached so
that we can do some attachment counting for multiattach
volumes being detached from instances on the same host.
Change-Id: I751fcb7532679905c4279744919c6cce84a11eb4
Related-Bug: #1752115
When we run detach_volume(), the guest has to respond to the ACPI
eject request in order for us to proceed. It may not do this at all
if the volume is mounted or in-use, or may not by the time we time out
if lots of dirty data needs flushing. Right now, we let the failure
exception bubble up to our caller and we log a nasty stack trace, which
doesn't really convey the reason (and that it's an expected and
reasonable thing to happen).
Thus, this patch catches that, logs the situation at warning level and
avoids the trace.
Change-Id: I3800b466a50b1e5f5d1e8c8a963d9a6258af67ee
Closes-Bug: #1750680
Many compute drivers override the driver capabilities dict [1]. The
code should be using dict.get() to avoid throwing KeyErrors if the
overriding dictionaries do not have the corresponding keys. If the
key is not found it will be assumed the the capability is not supported
and default to false. This ensures that no drivers are broken because
they are missing a capability.
[1] https://github.com/openstack/nova/blob/5251f18d87/nova/virt/driver.py#L124-L134
Change-Id: I1fa04fa110f2c65e10c065c61f2f0f58c1fad646
Closes-Bug: #1746608
Not all volume types put a 'volume_id' entry in the
connection_info['data'] dict. This change uses a new
utility method to look up the volume_id in the connection_info
data dict and if not found there, uses the 'serial' value
from the connection_info, which we know at least gets set
when the DriverVolumeBlockDevice code attaches the volume.
This also has to update pre_live_migration since the connection_info
dict doesn't have a 'volume_id' key in it. It's unclear what
this code was expecting, or if it ever really worked, but since
an attached volume represented by a BlockDeviceMapping here has
a volume_id attribute, we can just use that. As that code path
was never tested, this updates related unit tests and refactors
the tests to actually use the type of DriverVolumeBlockDevice
objects that the ComputeManager would be sending down to the
driver pre_live_migration method. The hard-to-read squashed
dicts in the tests are also re-formatted so a human can actually
read them.
Change-Id: Ie02d298cd92d5b5ebcbbcd2b0e8be01f197bfafb
Closes-Bug: #1746609
Add multiattach support to libvirt driver, by updating the
xml configuration info if the multiattach support is turned
on for a volume and set the virt driver capability
'support_multiattach' to true. This capability is set to false
for all the other drivers.
Also the attach function in nova/virt/block_device.py is updated
to call out to Cinder in case of each attachment request for
multiattach volumes, which is needed for Cinder in order to track
all attachments for a volume and be able to detach properly.
Co-Authored-By: Matt Riedemann <mriedem.os@gmail.com>
Partially-implements: blueprint multi-attach-volume
Change-Id: I947bf0ad34a48e9182a3dc016f47f0c9f71c9d7b
The Cinder 3.48 API provides a shared_targets and service_uuid
field in the volume resource which tells the caller whether or
not it should lock operations on that volume.
This change adds that logic to the DriverVolumeBlockDevice attach
and detach flows by first trying to get the volume at the 3.48
microversion and if that's not available, it simply falls back
to get the volume the same as before.
If 3.48 is available and the volume storage backend uses shared
targets, we synchronize the attach/detach operations using the
volume service_uuid, which is based on the storage backend and
is also configurable by the deployer on the Cinder side.
This is a nice to have protection for "normal" volumes but
is really needed for multiattach volumes to be detached safely.
See Cinder blueprint add-shared-targets-flag-to-volume for details.
Part of blueprint multi-attach-volume
Depends-On: I3c07cd8458d55535a71626ffaa8ca50deb3ca3dd
Change-Id: I5e96602184242fb9017c0434b445a3875f3b149a
BDMs are exposed to drivers via DriverBlockDevice. This will be used
as a disk serial number in a subsequent change to the libvirt driver.
Part of bp local-disk-serial-numbers
Change-Id: I8609a867039af137bb3d05de55285b10894a507b
This is a minor tidy-up in current code, as it allows volume_id and
volume_size to be inherited by all subclasses of
DriverVolumeBlockDevice. However, it's primary purpose it to make it
cleaner to add uuid to all DriverBlockDevice subclasses in a subsequent
patch.
Part of bp local-disk-serial-numbers
Change-Id: Ifabfaacf8752923493a78248593d2727a8ce4803
The old volume attach flow would pass the mountpoint,
which is the BlockDeviceMapping.device_name, to the
os-attach volume action API. With the new flow, apparently
the mountpoint is expected to be passed to the update
attachment API via the connector dict, which is not obvious
and if not provided, causes Cinder to default the mountpoint
to "/dev/na" which is wrong.
We work around this in Nova by providing the mountpoint in a
copy of the connector dict and pass that to attachment_update,
and update the two places in the code that are updating an
attachment (the normal driver block device attach code and
swap volume). Long-term this should be fixed in the Cinder
attachments update API, but that requires a microversion so
we need to handle it client-side for now.
Change-Id: I11ba269c3f7a2e7707b2b7e27d26eb7a2c948a82
Partial-Bug: #1737779
This plumbs in the new-style volume attachment support to the
virt driver block device code which does the actual work of
attaching the volume via the driver and completing the attachment
with cinder (the thing that makes the volume status "in-use").
At this point, none of the new flow is exercised outside of tests
because we are not yet setting the attachment_id when attaching
volumes, that comes in a later change to the API.
It's worth noting that when nova creates a volume during boot
from volume for a source_type=blank/image/snapshot BDM, we won't
have an attachment_id for that volume so we'll attach using the
old flow. For now this is OK, but might be something we need to
revisit in the future when we eventually want to remove the old
flow.
The structure here is to separate the old/new attach flows into
separate methods, despite quite a bit of copy/paste code in both
places. A single method using conditionals in different places
is arguably uglier (as seen in the test code) and we could likely
consolidate some of the common code into helper methods later.
Note that test_refresh_connection_info_with_attachment_id is
removed since it's now redundant with test_refresh_connection.
Co-Authored-By: Matt Riedemann <mriedem.os@gmail.com>
Part of blueprint cinder-new-attach-apis
Change-Id: Ib1b6b223c9d04579828d47607006ecd98b472e5a
We can avoid all of the stashed connector hulabaloo
when detaching a volume if we're using a new style
attachment, because we don't need a host connector
in that case, stashed or not, we just delete the
attachment and we're done. This also helps to avoid
some confusion about whether or not we need to stash
a connector in the connection_info for the new style
attachment flow (we don't).
Part of blueprint cinder-new-attach-apis
Change-Id: I1404842f91279dd40ec9e03ccbbfe11cfc48520c
The new Cinder attach/detach flow stores the connection_info for each
attachment. This patch adds the use of attachment_get to
refresh_connection_info as opposed to using initialize_connection in
case the new flow has been used to create the attachment.
Co-authored-by: Matt Riedemann <mriedem.os@gmail.com>
Change-Id: I9a62b915fc0b9406613c14434793eb52e602df1e
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
This addresses some of the nit comments from change:
I7a53e08f3fad6abb27a1d8ad425b4f916341cab3
The TODOs in the test_compute_mgr are clarified to explain
that rather than completely move those tests, which we don't
want to do since we still want test coverage on the compute
manager code, what we really want is test coverage for the
detach and driver_detach methods that live in
DriverVolumeBlockDevice now.
Change-Id: I07a05a52a832f9e2687369666c6140c076412856
This change drops the encryptor classes and supporting code from the
codebase in favor of the classes provided by os-brick. This is made
possible by the following os-brick change that introduced new encryption
provider constants during Ocata :
Ic155bd29d46059832cce970bf60375e7e472eca6
Thanks to the following bugfix also released as part of 1.11.0 for Ocata
the constants present in os-brick also support the use of the deprecated
legacy class paths from Nova, for example
nova.volume.encryptors.luks.LuksEncryptor, while using the os-brick
provided classes :
I3ec6e3fe919bc03d158da04a18fb8b651002ed52
Implements: blueprint switch-to-os-brick-encryptor-classes
Change-Id: I37ffc90c0bd57029fced251b5cfd7cd4318a0292
Depends-On: Iae12605dc7d0607e78020a24b5b8801606c2f169
Use the new Cinder V3 attachment delete method
during detach if the BDM has an attachment_id in it.
This will only be present in the BDM if/when the
new attachment_create API is called. Otherwise, we
revert to the old calls.
Edge cases are handled in separate patches.
Partially Implements: blueprint cinder-new-attach-apis
Co-Authored-By: Steve Noyes <steve.noyes@oracle.com>
Change-Id: I91b9a60268354ffbed86b1e7d173906cfd7b97bd
This change moves all detach logic found within the compute manager down
into the DriverVolumeBlockDevice driver bdm class as was previously done
for attach logic in the following change :
I5b9c3e2d959c602fa22f49db681da918ae0adcea
The logic used to detach a volume should remain unchanged and as such
there are only are limited changes made to the to the compute tests.
TODO notes have also been left within compute tests that should in
future be moved across into the virt block_device tests.
Change-Id: I7a53e08f3fad6abb27a1d8ad425b4f916341cab3
This patch finishes to remove the 'check_attach' call from Nova
completely. As Cinder already performs the required checks as part
of the 'reserve_volume' (os-reserve) call it is unnecessary to check the
statemachine in Nova also and it can lead to race conditions.
The missing 'reserve_volume' call is added to the BFV flow. In case of
build failure the volume will be locked in 'attaching' state until the
instance in ERROR state is cleaned up.
We also check AZ for each volume attach operation which we haven't
done for unshelve. A release note is added to enable 'cross_az_attach'
in case the user does not care about AZ.
The compute service version had to be bumped as the old computes still
perform 'check_attach', which will fail when the API reserves the
volume and the volume state moves to 'attaching'. If the computes
are not new enough the old check will be called as opposed to
'reserve_volume'.
Closes-Bug: #1581230
Change-Id: I3a3caa4c566ecc132aa2699f8c7e5987bbcc863a
1.As mentioned in [1], we should avoid using
six.iteritems to achieve iterators. We can
use dict.items instead, as it will return
iterators in PY3 as well. And dict.items/keys
will more readable. 2.In py2, the performance
about list should be negligible, see the link [2].
[1] https://wiki.openstack.org/wiki/Python3
[2] http://lists.openstack.org/pipermail/openstack-dev/2015-June/066391.html
The patch list:
1. cells.
2. compute api.
3. image.
4. network.
5. objects.
6. scheduler.
7. virt.
8. other resources.
Partial-Implements: blueprint replace-iteritems-with-items
Change-Id: Ic6e469eb80ee1774de1374bb36f38b5134b6b311
Fixes volume related unit tests.
Fixes non-sortable None items.
Fixes __getattr__ infinite recursion.
Fixes is_dict_like method. Dicts in python 3.4 do not
have the 'has_key' method.
Partially Implements: blueprint goal-python35
Change-Id: I97efc09f7657436f706b08e0b2795f0e59ac1dcd