Unable to create an instance based on an encrypted volume snapshot

[Lee Yarwood]

Description
===========
Nova is currently unable to create and then boot from volumes from encrypted volume snapshots when the original volume_type is not provided as part of the block_device_mapping request to n-api. Failure to provide this will result in the following error when attempting to launch the instance:

Details: {'code': 500, 'created': '2019-11-21T16:56:58Z', 'message': 'Build of instance 176ff71f-1dff-433b-92c7-5a15bade375f aborted: Invalid input received: Invalid input received: Invalid volume_type provided: 9142150e-70fe-4b14-942f-015025de4a68 (requested type is not compatible; recommend omitting the type argument). (H'}"

Steps to reproduce
==================

* Create an encrypted volume snapshot
* Attempt to create an instance based on this without providing a volume_type in the block_device_mapping.

Expected result
===============
Nova copies the original volume_type if one is not provided in the request.

Actual result
=============
Nova fails to copy the original volume_type leading to a failure when attempting to create a volume based on the encrypted volume snapshot as the types do not match.

Environment
===========
1. Exact version of OpenStack you are running. See the following
  list for all releases: http://docs.openstack.org/releases/

   master

2. Which hypervisor did you use?
   (For example: Libvirt + KVM, Libvirt + XEN, Hyper-V, PowerKVM, ...)
   What's the version of that?

   Libvirt + KVM

2. Which storage type did you use?
   (For example: Ceph, LVM, GPFS, ...)
   What's the version of that?

   N/A

3. Which networking type did you use?
   (For example: nova-network, Neutron with OpenVSwitch, ...)

   N/A

Logs & Configs
==============

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/694497
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=5679a0bf99c17ff336fa520c9cdfad5156c6c9d2
Submitter: Zuul
Branch: master

commit 5679a0bf99c17ff336fa520c9cdfad5156c6c9d2
Author: Lee Yarwood <email address hidden>
Date: Fri Nov 15 09:57:27 2019 +0000

    block_device: Copy original volume_type when missing for snapshot based volumes

    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

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/train
Review: https://review.opendev.org/696683

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/stein
Review: https://review.opendev.org/696686

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/rocky
Review: https://review.opendev.org/697260

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/queens
Review: https://review.opendev.org/697261

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/696683
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=059dc01ae027f00ffffbaa9ee8a3c958031829ce
Submitter: Zuul
Branch: stable/train

commit 059dc01ae027f00ffffbaa9ee8a3c958031829ce
Author: Lee Yarwood <email address hidden>
Date: Fri Nov 15 09:57:27 2019 +0000

    block_device: Copy original volume_type when missing for snapshot based volumes

    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.

    Conflicts:
            nova/virt/block_device.py

    NOTE(lyarwood): Due to I30a49c9e085cffc071d0ba332db67945e116bc80 not
    being present in stable/train.

    Closes-Bug: #1853495
    Change-Id: Ic749c49e227e41732dbe04acea303b303acd264a
    (cherry picked from commit 5679a0bf99c17ff336fa520c9cdfad5156c6c9d2)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/696686
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=95bf4a1e1594611e987f88b470cc02a626373ab4
Submitter: Zuul
Branch: stable/stein

commit 95bf4a1e1594611e987f88b470cc02a626373ab4
Author: Lee Yarwood <email address hidden>
Date: Fri Nov 15 09:57:27 2019 +0000

    block_device: Copy original volume_type when missing for snapshot based volumes

    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.

    Conflicts:
            nova/virt/block_device.py
            nova/tests/unit/virt/test_block_device.py

    NOTE(lyarwood): Due to I4205c00311f389907dcc390869414687ac03b7f5 not
    being present in stable/stein. As a result the call to the
    volume_api.create doesn't proivide the snapshot argument as a keyword.

    Closes-Bug: #1853495
    Change-Id: Ic749c49e227e41732dbe04acea303b303acd264a
    (cherry picked from commit 5679a0bf99c17ff336fa520c9cdfad5156c6c9d2)
    (cherry picked from commit 059dc01ae027f00ffffbaa9ee8a3c958031829ce)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/nova 20.1.0 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/nova 19.1.0 release.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Lee Yarwood (<email address hidden>) on branch: stable/rocky
Review: https://review.opendev.org/697260

[OpenStack Infra (hudson-openstack)]

Change abandoned by Lee Yarwood (<email address hidden>) on branch: stable/queens
Review: https://review.opendev.org/697261