On Thu, Jul 2, 2015 at 7:05 PM, Matt Riedemann <[email protected]> wrote:
> > > On 7/2/2015 4:12 AM, Deepak Shetty wrote: > >> >> >> On Wed, Jul 1, 2015 at 5:17 AM, Mike Perez <[email protected] >> <mailto:[email protected]>> 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: >> [email protected]?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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
