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 <dpkshe...@gmail.com> wrote: > > > On Thu, Jul 2, 2015 at 7:05 PM, Matt Riedemann <mrie...@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 <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. >> > > 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-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >
__________________________________________________________________________ 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