Imaged encrypted volumes fail to deploy new volumes

Bug #1911818 reported by Eric Miller
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Cinder
Incomplete
Low
Unassigned

Bug Description

We have a Stein environment, deployed with Kolla Ansible on CentOS 7, that generates an error when performing the following steps:
1) Create a volume on an encrypted backend
2) Create an image from this volume
3) Create a volume from this image on the encrypted backed (error occurs here)

The volume created in step 3 has a status of "error". The error was logged in the cinder-scheduler.log. I attached the error as a file to this bug (general "Internal Server error" in the Glance client).

The exact commands for reproducing the issue are, where gp1_encrypted is the encrypted Ceph backend:

openstack volume create \
--type gp1_encrypted \
--size 10 \
EricTestVolumeEncrypted

openstack image create \
--volume EricTestVolumeEncrypted \
EricTestImageFromEncryptedVolume

openstack volume create \
--type gp1_encrypted \
--image EricTestImageFromEncryptedVolume \
--size 10 \
EricTestVolumeFromEncryptedImage

I thought that Glance possibly was having issues connecting to Barbican, so I checked the glance-api.conf file, and sure enough, the [barbican] stanza was missing. Ussuri and later versions of Kolla Ansible include this stanza that includes the auth_endpoint. So, I created a patch for the file in Kolla Ansible to include this in this environment, re-deployed, the glance-api services restarted successfully, and I confirmed that the stanza was indeed added successfully to all of the glance-api containers.

However, the problem is still there.

I had read here:
https://specs.openstack.org/openstack/cinder-specs/specs/wallaby/image-encryption.html

that:
2.2. A user wants to create an encrypted image from a volume. The volume uses an encrypted volume type (LUKS-based). The target image is not to be re-encrypted but will instead reuse the LUKS encryption and key. This use case is already implemented as part of the default behavior of Cinder.

Maybe this is referring to a newer version of Cinder, and/or Glance, than Stein? It did not specify which version started to support this, so maybe we're in need of an upgrade?

Thanks!

Eric

Revision history for this message
Eric Miller (erickmiller) wrote :
Revision history for this message
Eric Harney (eharney) wrote :

The log file you attached shows that Cinder got an HTTPInternalServerError (HTTP 500) from Glance when trying to download the image, so there should be an error related to that failure in the Glance logs. This will be needed to determine what the failure actually is.

Stein should be sufficient for the use case you are describing.

Changed in cinder:
status: New → Incomplete
Changed in cinder:
importance: Undecided → Low
tags: added: deployment encryption volume
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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