I am not entirely sure but it seems that cinder internally needs only the volume type id when updating or deleting encryption type [1][2][3]. When an encryption type is created via the API it must be connected to a volume type which suggests that volume type id should be enough for identifying the encryption type.
Also when the /v3/{project_id}/types/{volume_type_id}/encryption/{encryption_id} request is send with valid values for {project_id} and {volume_type_id} the request will pass as long as {encryption_id} contains any value (e.g. "abcd") and the volume type has an encryption type.
I am not entirely sure but it seems that cinder internally needs only the volume type id when updating or deleting encryption type [1][2][3]. When an encryption type is created via the API it must be connected to a volume type which suggests that volume type id should be enough for identifying the encryption type.
Also when the /v3/{project_ id}/types/ {volume_ type_id} /encryption/ {encryption_ id} request is send with valid values for {project_id} and {volume_type_id} the request will pass as long as {encryption_id} contains any value (e.g. "abcd") and the volume type has an encryption type.
[1] https:/ /github. com/openstack/ cinder/ blob/4580c56058 a39726dd174b1ae fa7b3eacc63904c /cinder/ api/contrib/ volume_ type_encryption .py#L113 /github. com/openstack/ cinder/ blob/4580c56058 a39726dd174b1ae fa7b3eacc63904c /cinder/ api/contrib/ volume_ type_encryption .py#L151 /github. com/openstack/ cinder/ blob/e8f03523e8 d244fb9c1ecceb0 91784cc37d63b0d /cinder/ db/api. py#L873
[2] https:/
[3] https:/