<div dir="ltr"><div><div><div>Oh, just to be clear, I don't mean to discard what you fixed<br></div>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<br><br></div>thanx,<br></div>deepak<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 2, 2015 at 8:57 PM, Deepak Shetty <span dir="ltr"><<a href="mailto:dpkshetty@gmail.com" target="_blank">dpkshetty@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Thu, Jul 2, 2015 at 7:05 PM, Matt Riedemann <span dir="ltr"><<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
<br>
On 7/2/2015 4:12 AM, Deepak Shetty wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
<br>
<br>
On Wed, Jul 1, 2015 at 5:17 AM, Mike Perez <<a href="mailto:thingee@gmail.com" target="_blank">thingee@gmail.com</a><br></span><div><div>
<mailto:<a href="mailto:thingee@gmail.com" target="_blank">thingee@gmail.com</a>>> wrote:<br>
<br>
On 12:24 Jun 26, Matt Riedemann wrote:<br>
<snip><br>
> So the question is, is everyone OK with this and ready to make that change?<br>
<br>
Thanks for all your work on this Matt.<br>
<br>
<br>
+100, awesome debug, followup and fixing work by Matt<br>
<br>
<br>
I'm fine with this. I say bite the bullet and we'll see the CI's<br>
surface that<br>
aren't skipping or failing this test.<br>
<br>
<br>
Just curious, shouldn't this mean we need to have some way of Cinder<br>
querying Nova<br>
for "do u have this capability" and only then setting the 'encryption'<br>
key in conn_info ?<br>
<br>
Better communication between nova and cinder ?<br>
<br>
thanx,<br>
deepak<br>
<br>
<br>
<br></div></div><span>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</span></blockquote>
<br>
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].<br>
<br>
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.<br></blockquote><div><br></div></div></div><div>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.<br><br></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br></blockquote><div><br></div></span><div>Definitely what u have proposed/fixed is appreciated. But its a workaround, the better way seems to be improving the Nova-Cinder communication ?<br><br></div><div>thanx,<br></div><div>deepak<br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[1] <a href="http://git.openstack.org/cgit/openstack/nova/tree/nova/volume/encryptors/__init__.py#n47" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/nova/tree/nova/volume/encryptors/__init__.py#n47</a><br>
[2] <a href="http://git.openstack.org/cgit/openstack/nova/tree/nova/volume/encryptors/base.py#n28" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/nova/tree/nova/volume/encryptors/base.py#n28</a><span><font color="#888888"><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann</font></span><div><div><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></span></div><br></div></div>
</blockquote></div><br></div>