OpenStack Compute (nova)

Unable to create an instance based on an encrypted volume snapshot

  1. Series train
  2. Bug #1853495
Bug #1853495 reported by Lee Yarwood
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Fix Released
Undecided
Lee Yarwood
Stein
Fix Committed
Undecided
Lee Yarwood
Train
Fix Committed
Undecided
Lee Yarwood

Bug Description

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)
Changed in nova:
assignee: nobody → Lee Yarwood (lyarwood)
status: New → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to nova (master)

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

Changed in nova:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (stable/train)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (stable/stein)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (stable/rocky)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (stable/queens)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to nova (stable/train)

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)

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to nova (stable/stein)

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)

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/nova 20.1.0

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/nova 19.1.0

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on nova (stable/rocky)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on nova (stable/queens)

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.