[storage] Add Crypto middle end volume

[glimchb]

Signed-off-by: Boris Glimcher [email protected]

[sandersms]

Should the Crypto functionality be included in the middle end protobuf or should there be a separate common crypto capability that can be tied to the function (Storage, Security, Networking, etc.) that would create, delete, update, ... the capability?

Perhaps we can iterate on that aspect of the common functionality.

[glimchb]

Should the Crypto functionality be included in the middle end protobuf or should there be a separate common crypto capability that can be tied to the function (Storage, Security, Networking, etc.) that would create, delete, update, ... the capability?

Perhaps we can iterate on that aspect of the common functionality.

d@re (data at rest encryption) is only applicable for storage

we can definitely iterate on this common once we have another example that uses the same, we can easily move it around to a common place

[sandersms]

LGTM - Approved

[glimchb]

• opened think of a better name for message Crypto #210 to think about better name
• will try to implement now the code, to show the usage example Add crypto device example opi-spdk-bridge#49

[jainvipin]

some comments @glimchb

[jainvipin]

the flat API structure is evident here v1/volumes is very generic, if we preceed it with v1/middleend/volumes that would decouple it from the backend volumes and overlap.

[glimchb]

agree, part of #188

[jainvipin]

Is it a shared secret or a private key?

[jainvipin]

do we need to provide secret for initial vector or do we believe use of IV is perhaps a stale thing?

[glimchb]

no idea, this is just first draft, let's discuss

[jainvipin]

same comment about stats as in other PRs

[jainvipin]

minor, why do we call the field volume it should be called crypto? e.g. what if we have other service applied on the volume, would that also be called volume in the create/update requests?

[glimchb]

will rename, thanks