[openstack-dev] [nova][cinder][qa] encrypted volumes tests don't actually test encrypted volumes for most backends
dpkshetty at gmail.com
Thu Jul 2 15:27:04 UTC 2015
On Thu, Jul 2, 2015 at 7:05 PM, Matt Riedemann <mriedem at linux.vnet.ibm.com>
> 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:
>> > So the question is, is everyone OK with this and ready to make that
>> 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 ?
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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  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 .
> 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 ?
> Matt Riedemann
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev