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:
parent
5fe3e7b188
commit
acbd671fcd
|
@ -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
|
||||
---------------
|
Loading…
Reference in New Issue