Set encrypted key in connection_info during initialize
There are encrypted volume tests in Tempest which are passing
in the ceph job but the encryption providers in nova (luks and
cryptsetup) are not actually being called in nova because the
'encrypted' key isn't being set in connection_info for the Rbd
volume driver, and nova is keying off that value to determine
if it needs to run it's encryption providers.
So the tests are passing in the ceph job but it's a total false
positive and the API should actually fail - either the cinder
API to create the encrypted volumes if the Rbd volume driver in
Cinder doesn't support encryption, or the volume attach call in
nova if it can't encrypt the connected volume, either way the
test should fail until that support is baked into nova.
I'm not aware of any kind of 'supports_encryption' or 'encryptable'
capability flag for cinder volume drivers, but that might be
needed for the volume create API to fail if trying to create a
volume from an encrypted volume type where the volume driver
itself doesn't support encryption - but maybe it's only a nova
problem since nova has the encryption providers.
This is fixed generically in the VolumeManager's
initialize_connection method where we check for the encrypted
flag being set in the volume driver method and if not, the
manager sets it based on the volume.encryption_key_id value.
We do this globally since there are other volume drivers besides
rbd that aren't setting the encrypted key in connection_info,
but we test rbd in the gate via the ceph job so most of the
bug tracking is around validation of the ceph job.
Related Nova change: I8efc2628b09d4e9e59831353daa080b20e17ccde
Depends-On: I8548d41095513b9e669f773e3f35353e9228ead9
DocImpact: Attaching 'encrypted' RBD volumes to a Nova server
instance created from the libvirt virt driver will fail
since RBD volume encryption is not currently supported in
Nova's libvirt driver.
Closes-Bug: #
1440227
Related-Bug: #
1463525
Change-Id: I03f8cae05cc117e14f7482115de685fc9f3fa54a