<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 23, 2014 at 1:30 AM, Preston L. Bannister <span dir="ltr"><<a href="mailto:preston@bannister.us" target="_blank">preston@bannister.us</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">John,<div><br></div><div>As a (new) OpenStack developer, I just discovered the "CINDER_SECURE_DELETE" option.<br><br>As an *implicit* default, I entirely approve.  Production OpenStack installations should *absolutely* insure there is no information leakage from one instance to the next. </div><div><br></div><div>As an *explicit* default, I am not so sure. Low-end storage requires you do this explicitly. High-end storage can insure information never leaks. Counting on high level storage can make the upper levels more efficient, can be a good thing.<br></div></div></blockquote><div><br></div><div>Not entirely sure of the distinction intended as far as implicit/explicit... but one other thing I should probably point out; this ONLY applies to the LVM driver, maybe that's what you're getting at.  Would be better probably to advertise as an LVM Driver option (easy enough to do in the config options help message). </div><div><br></div><div>Anyway, I just wanted to point to some of the options like using io-nice, clear-size, blkio cgroups, bps_limit......</div><div><br></div><div>It doesn't suck as bad as you might have thought or some of the other respondents on this thread seem to think.  There's certainly room for improvement and growth but it hasn't been completely ignored on the Cinder side.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br>The debate about whether to wipe LV's pretty much massively depends on the intelligence of the underlying store. If the lower level storage never returns accidental information ... explicit zeroes are not needed. <br><br><br></div><div><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 22, 2014 at 11:15 PM, John Griffith <span dir="ltr"><<a href="mailto:john.griffith8@gmail.com" target="_blank">john.griffith8@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"><div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 21, 2014 at 9:17 AM, Duncan Thomas <span dir="ltr"><<a href="mailto:duncan.thomas@gmail.com" target="_blank">duncan.thomas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">For LVM-thin I believe it is already disabled? It is only really<br>
needed on LVM-thick, where the returning zeros behaviour is not done.<br>
<div><div><br>
On 21 October 2014 08:29, Avishay Traeger <<a href="mailto:avishay@stratoscale.com" target="_blank">avishay@stratoscale.com</a>> wrote:<br>
> I would say that wipe-on-delete is not necessary in most deployments.<br>
><br>
> Most storage backends exhibit the following behavior:<br>
> 1. Delete volume A that has data on physical sectors 1-10<br>
> 2. Create new volume B<br>
> 3. Read from volume B before writing, which happens to map to physical<br>
> sector 5 - backend should return zeroes here, and not data from volume A<br>
><br>
> In case the backend doesn't provide this rather standard behavior, data must<br>
> be wiped immediately.  Otherwise, the only risk is physical security, and if<br>
> that's not adequate, customers shouldn't be storing all their data there<br>
> regardless.  You could also run a periodic job to wipe deleted volumes to<br>
> reduce the window of vulnerability, without making delete_volume take a<br>
> ridiculously long time.<br>
><br>
> Encryption is a good option as well, and of course it protects the data<br>
> before deletion as well (as long as your keys are protected...)<br>
><br>
> Bottom line - I too think the default in devstack should be to disable this<br>
> option, and think we should consider making the default False in Cinder<br>
> itself.  This isn't the first time someone has asked why volume deletion<br>
> takes 20 minutes...<br>
><br>
> As for queuing backup operations and managing bandwidth for various<br>
> operations, ideally this would be done with a holistic view, so that for<br>
> example Cinder operations won't interfere with Nova, or different Nova<br>
> operations won't interfere with each other, but that is probably far down<br>
> the road.<br>
><br>
> Thanks,<br>
> Avishay<br>
><br>
><br>
> On Tue, Oct 21, 2014 at 9:16 AM, Chris Friesen <<a href="mailto:chris.friesen@windriver.com" target="_blank">chris.friesen@windriver.com</a>><br>
> wrote:<br>
>><br>
>> On 10/19/2014 09:33 AM, Avishay Traeger wrote:<br>
>>><br>
>>> Hi Preston,<br>
>>> Replies to some of your cinder-related questions:<br>
>>> 1. Creating a snapshot isn't usually an I/O intensive operation.  Are<br>
>>> you seeing I/O spike or CPU?  If you're seeing CPU load, I've seen the<br>
>>> CPU usage of cinder-api spike sometimes - not sure why.<br>
>>> 2. The 'dd' processes that you see are Cinder wiping the volumes during<br>
>>> deletion.  You can either disable this in cinder.conf, or you can use a<br>
>>> relatively new option to manage the bandwidth used for this.<br>
>>><br>
>>> IMHO, deployments should be optimized to not do very long/intensive<br>
>>> management operations - for example, use backends with efficient<br>
>>> snapshots, use CoW operations wherever possible rather than copying full<br>
>>> volumes/images, disabling wipe on delete, etc.<br>
>><br>
>><br>
>> In a public-cloud environment I don't think it's reasonable to disable<br>
>> wipe-on-delete.<br>
>><br>
>> Arguably it would be better to use encryption instead of wipe-on-delete.<br>
>> When done with the backing store, just throw away the key and it'll be<br>
>> secure enough for most purposes.<br>
>><br>
>> Chris<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
</div></div><span><font color="#888888">--<br>
Duncan Thomas<br>
</font></span><div><div><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div></div><div class="gmail_extra">We disable this in the Gates "CINDER_SECURE_DELETE=False"</div><div class="gmail_extra"><br></div><div class="gmail_extra">ThinLVM (which hopefully will be default upon release of Kilo) doesn't need it because internally it returns zeros when reading unallocated blocks so it's a non-issue.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The debate of to wipe LV's or not to is a long running issue.  The default behavior in Cinder is to leave it enable and IMHO that's how it should stay.  The fact is anything that might be construed as "less secure" and has been defaulted to the "more secure" setting should be left as it is.  It's simple to turn this off.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Also, nobody seemed to mention that in the case of Cinder operations like copy-volume and the delete process you also have the ability to set bandwidth limits on these operations, and in the case of delete even specify different schemes (not just enabled/disabled but other options that may be less or more IO intensive).</div><div class="gmail_extra"><br></div><div class="gmail_extra">For further reference checkout the config options [1]</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks,</div><div class="gmail_extra">John</div><div class="gmail_extra"><br></div><div class="gmail_extra">[1]: <a href="https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py#L69" target="_blank">https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py#L69</a></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>