Open Stack

Oh, just to be clear, I don't mean to discard what you fixed
My intention was to discuss what would be a better way to fix this in
future thru a feature/blueprint, given there is a consensus

thanx,
deepak

On Thu, Jul 2, 2015 at 8:57 PM, Deepak Shetty <dpkshetty at gmail.com> wrote:

>
>
> 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/955524e2/attachment.html>