Open Stack

On Thu, Jul 2, 2015 at 7:05 PM, Matt Riedemann <mriedem at linux.vnet.ibm.com>
wrote:

>
>
> 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.
>

Yes I understand the issue, hence i said that why not cinder "checks" with
Nova whether it supports enc for volume-attach , nova returns yes/no and
based on that cinder accepts/rejects the 'create new enc volume' request.


> 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.
>
>
Definitely what u have proposed/fixed is appreciated. But its a workaround,
the better way seems to be improving the Nova-Cinder communication ?

thanx,
deepak


> [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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150702/b49f457f/attachment.html>