[openstack-dev] [nova][cinder][qa] encrypted volumes tests don't actually test encrypted volumes for most backends
Matt Riedemann
mriedem at linux.vnet.ibm.com
Thu Jul 2 13:35:42 UTC 2015
On 7/2/2015 4:12 AM, Deepak Shetty wrote:
>
>
> On Wed, Jul 1, 2015 at 5:17 AM, Mike Perez <thingee at gmail.com
> <mailto:thingee at gmail.com>> wrote:
>
> On 12:24 Jun 26, Matt Riedemann wrote:
> <snip>
> > So the question is, is everyone OK with this and ready to make that change?
>
> Thanks for all your work on this Matt.
>
>
> +100, awesome debug, followup and fixing work by Matt
>
>
> I'm fine with this. I say bite the bullet and we'll see the CI's
> surface that
> aren't skipping or failing this test.
>
>
> Just curious, shouldn't this mean we need to have some way of Cinder
> querying Nova
> for "do u have this capability" and only then setting the 'encryption'
> key in conn_info ?
>
> Better communication between nova and cinder ?
>
> thanx,
> deepak
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
I thought the same about some capability flag in cinder where the volume
driver would tell the volume manager if it supported encryption and then
the cinder volume manager would use that to tell if a request to create
a volume from an encryption type was possible. But the real problem in
our case is the encryption provider support, which is currently the luks
and cryptsetup modules in nova. However, the encryption provider is
completely pluggable [1] from what I can tell, the libvirt driver in
nova just creates the provider class (assuming it can import it) and
calls the methods defined in the VolumeEncryptor abstract base class [2].
So whether or not encryption is supported during attach is really up to
the encryption provider implementation, the volume driver connector code
(now in os-brick), and what the cinder volume driver is providing back
to nova during os-initialize_connection.
I guess my point is I don't have a simple solution besides actually
failing when we know we can't encrypt the volume during attach - which
is at least better than the false positive we have today.
[1]
http://git.openstack.org/cgit/openstack/nova/tree/nova/volume/encryptors/__init__.py#n47
[2]
http://git.openstack.org/cgit/openstack/nova/tree/nova/volume/encryptors/base.py#n28
--
Thanks,
Matt Riedemann
More information about the OpenStack-dev
mailing list