Add description about conflicts with non-encrypted volume types

This fixes a minor grammatical mistake as well

Change-Id: I755106e7d379980e9a1a050a3debcccb37f53285
Signed-off-by: Tobias Wolf <wolf@b1-systems.de>
This commit is contained in:
Tobias Wolf 2024-03-27 13:42:41 +01:00
parent 5fe3e7b188
commit acbd671fcd
1 changed files with 2 additions and 1 deletions

View File

@ -28,7 +28,7 @@ Use Cases
Proposed change
===============
Most peaces are already in place and do not to be changed for that feature to be implemented. The KeyManager implementation holds the key provided by the end user.
Most pieces are already in place and do not to be changed for that feature to be implemented. The KeyManager implementation holds the key provided by the end user.
- The most visible change is to be able to provide an encryption key ID to create volume.
- ``cinder.volume.volume_utils.clone_encryption_key()`` must be used to ensure keys can be deleted when the volume is deleted
@ -52,6 +52,7 @@ REST API impact
* Normal http response code(s): 202
* New optional ``parameter encryption_key_id`` indicates which encryption key ID from the KeyManager implementation should be used
* Maybe a new use of response code 409 may be needed if e.g. a encrypted snapshot volume should be copied with a different key
* 409 may be used to indicate if the volume type chosen does not support encryption at all as well, alternatively 400 is suitable in that case
Security impact
---------------