Open Stack

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