Volume backup restore fails from non-default encrypted type

[Markus Hentsch]

# Description

When the type of the volume, from which a backup is created, is a non-default encrypted type, restoring the backup will fail unless a target volume with the exact type is prepared beforehand. This is non-obvious to the user.

In case the user attempts to restore such backup without referencing an existing or specifically prepared volume as the target, the newly created volume will enter "error_restoring" state and the error message about the mismatched type is invisible to the user (only in Cinder log).
Furthermore, a user is unable to determine the exact expected volume type based on the backup metadata alone.

Also, volume type deletion is possible despite volume backups referencing it still exists.

# How to reproduce

The following was executed on a DevStack environment:

```
# create an encrypted (non-default) volume type
openstack volume type create \
--property volume_backend_name='lvmdriver-1' \
--encryption-provider luks \
--encryption-cipher aes-xts-plain64 \
--encryption-key-size 256 \
--encryption-control-location front-end \
lvmdriver-1-LUKS

# create encrypted volume
openstack volume create --size 2 --image "cirros-0.6.2-x86_64-disk" --type lvmdriver-1-LUKS encrypted-volume

# create backup from encrypted volume
openstack volume backup create --name volume-backup encrypted-volume

# restore backup into new volume
openstack volume backup restore volume-backup new-volume-restored-from-backup

# check the status of the volume
openstack volume show new-volume-restored-from-backup -f value -c status

    error_restoring
```

Using `openstack volume show` does not present any detailed error message.

When inspecting the log output of the Cinder Backup service, the following log message was seen:

```
cinder.exception.EncryptedBackupOperationFailed: The source volume
type 'a935d148-0d0f-4c25-8459-669f77871c92' is different than the
destination volume type '165c9c5e-477a-4a35-965b-58e504ff4ae3'.
```

# Implications

The `openstack volume backup restore` command seems to lack a parameter for specifying a volume type. The same goes for the `/v3/{project_id}/backups/{backup_id}/restore` API. Thus, it is only possible to restore such a backup by creating an empty and sufficiently sized volume beforehand and then force-restoring onto it:

```
openstack volume create --size 2 --type lvmdriver-1-LUKS empty-volume
openstack volume backup restore --force volume-backup empty-volume
```

The backup is strictly dependent on the volume type of the source volume. However, if all related volumes are deleted, the volume type can be deleted freely as well regardless of whether backups still exist that depend on it:

```
openstack volume delete empty-volume encrypted-volume

# switch to admin and delete the volume type (DevStack example)
source openrc admin admin
openstack volume type delete lvmdriver-1-LUKS
```

Now, the volume type that the backup originally was based on has been deleted, rendering the backup unusable because the matching volume type ID cannot be achieved by any new volume.

# Summary

In summary, this poses the following problems:

1. If the source volume type of a volume from which a volume backup is created is an encrypted non-default volume type, restoring the backup will fail unless a volume with the exact type is created beforehand and overwritten by the backup. Users are unable to specify a volume type in `openstack volume backup restore` (and the corresponding API) and cannot restore the backup on a new (yet-to-be-created) volume.

2. Even if users were able to specify a volume type, the source volume type is not shown in `openstack volume backup show` or the corresponding API. A user cannot determine the correct volume type based on the backup resource alone. If the source volume was deleted, users cannot look it up. Only the Cinder Backup service log file contains the mismatching type IDs as shown in the quoted error message above.

3. The existence of the backup based on the encrypted type does not prevent the deletion of the volume type in Cinder like it happens for volumes. Deletion of the volume type effectively renders the backup unusable.

# Notes

Here is the code part in Cinder Backup that compares the volume type IDs:

https://github.com/openstack/cinder/blob/d46e2ebbd719b01aa3497853332fda1b724c281d/cinder/backup/driver.py#L204-L213