Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1879190

Summary: unable to boot instance from encrypted volume created from a glance image of an encrypted volume
Product: Red Hat OpenStack Reporter: Brian Rosmaita <brian.rosmaita>
Component: openstack-novaAssignee: Lee Yarwood <lyarwood>
Status: CLOSED ERRATA QA Contact: bkopilov <bkopilov>
Severity: high Docs Contact:
Priority: high    
Version: 16.1 (Train)CC: dasmith, eglynn, gcharot, jamsmith, jhakimra, kchamart, lyarwood, pmorey, sbauza, scohen, sgordon, vromanso
Target Milestone: z2Keywords: Patch, Regression, Triaged
Target Release: 16.1 (Train on RHEL 8.2)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openstack-nova-20.4.1-1.20200914172612.el8ost Doc Type: Bug Fix
Doc Text:
This bug fix enables you to boot an instance from an encrypted volume when that volume was created from an image that in turn was created by uploading an encrypted volume to the Image Service as an image.
 Story Points: ---
Clone Of:
: 1900539 (view as bug list) Environment:
Last Closed: 2020-10-28 15:39:36 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1668213, 1900539    

Description Brian Rosmaita 2020-09-15 16:03:53 UTC 
Description of problem:
This is a regression caused by the fix for BZ 1801255.

Version-Release number of selected component (if applicable):
Observed in 16.1.

Steps to Reproduce:
1. Let Image-1 be a "regular" (non-encrypted, bootable) image in Glance.
2. Create volume V-1 in Cinder from Image-1 specifying encrypted volume-type T-1.
3. Boot an instance from V-1 (make sure delete-on-terminate is false).  Works fine.  Delete the instance to free up the volume.
4. Call cinder upload-to-image on V-1 to create Image-2.
5. Create volume V-2 in Cinder specifying encrypted volume-type T-1 from Image-2.
6. Boot an instance from V-2.

Actual results:
ERROR (BadRequest): Image None is unacceptable: Direct booting of an image uploaded from an encrypted volume is unsupported. (HTTP 400)

Expected results:
Working instance booted from volume.

Additional info:
If we bypass the check at https://review.opendev.org/#/c/707738/3/nova/compute/api.py@894, the instance goes 'active' and is operable (you can ssh into it).  (Of course, we don't want to bypass the check, it just needs to be made aware that we are booting from a volume, not trying to boot from an image.)
Comment 8 bkopilov 2020-09-30 13:20:37 UTC 
Solved,
https://rhos-ci-jenkins.lab.eng.tlv2.redhat.com/view/Phase3/view/OSP%2016.1/view/storage/job/DFG-all-unified-16.1_director-rhel-virthost-3cont_2comp_3ceph-ipv4-geneve-ceph-native-default/64/testReport/tempest_storage_plugin.tests.scenario.test_image_encryption_key_manage/TestImageEncryptedKeyManage/test_create_encrypted_image_from_luks_barbian_payload_instance_id_d773fa51_a13a_4833_9185_cef733d9d6e7_/
Comment 14 errata-xmlrpc 2020-10-28 15:39:36 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Red Hat OpenStack Platform 16.1 bug fix and enhancement advisory), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:4284