Comment 2 for bug 1708768

(I'm the author of the barbican charms)

It's not so much that the Barbican charm needs to support cinder, as cinder needs to be configurable to use Barbican: Please see here: (mitaka) https://docs.openstack.org/mitaka/config-reference/block-storage/volume-encryption.html and (newton) https://docs.openstack.org/newton/config-reference/block-storage/volume-encryption.html

i.e. cinder would need updating to provide a [key_manager] section.

A bigger issue is that the Barbican charm isn't 'production' yet, as there is no suitable HSM configuration defined for it. The 'out-of-the-box no hsm' configuration might be suitable, soft-hsm doesn't work due to a missing OpenSSL feature on Xenial (#1611393), and no hardware HSM has been identified as a solution to work against. Please see bug: #1615211 for more details.

So, from a Barbican perspective, it can work with just the built in secret system. However, there's no HA (tested) on the Barbican charm and there's probably a little work in getting it fully production level (which we want to do!) with just the built in system.

It boils down to the requirements of the user. i.e. with some work we would be able to support Barbican / internal secret store / encrypted volumes (with a change to the Cinder charm) if it's okay that those volume keys are stored in the database, rather than an HSM. If they have to be stored in an HSM, then the HSM needs selecting, and a configuration charm for it needs to be produced.

Hope that helps with some background.