On 7/2/2015 4:12 AM, Deepak Shetty wrote:


On Wed, Jul 1, 2015 at 5:17 AM, Mike Perez <thin...@gmail.com
<mailto:thin...@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-requ...@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


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to