Open Stack

Hello Jeff,

	I understand that but does that mean it HAS to be done right away?
I mean, performances for the rest of the VMs are sacrificed over security concern
(which are legitimate) but still have an impact over the remainder of the EBS 
volumes being attached to other VMs.   There're no better ways that could
be implemented to deal with that?  Or maybe some faster ways ?   What 
if the LVM would be kept for a bit longer and be deleted slowly but surely?

Thank you very much,

Dave

-----Original Message-----
From: Jeffrey Walton [mailto:noloader at gmail.com] 
Sent: November-01-13 9:21 PM
To: David Hill
Cc: openstack at lists.openstack.org
Subject: Re: [Openstack] Wiping of old cinder volumes

On Fri, Nov 1, 2013 at 8:33 PM, David Hill <david.hill at ubisoft.com> wrote:
> Hello John,
>
>         Well, if it has an impact on the other volumes that are still being used by
> some other VMs, this is worse in my opinion as it will degrade the service level
> of the other VMs that need to get some work done.  If that space is not immediately
> needed we can take our time to delete it or at least delay the deletion.  Or perhaps
> the scheduler should try to delete the volumes when there's less activity on the storage
> device (SAN, disks, etc) and even throttle the rate at which the bites are overwritten
> by zeros.    The fact is that our internal cloud users can delete multiple volumes at
> the same time and thus, have an impact on other users VMs that may or may not
> be doing critical operations and sometimes, Windows may even blue screen because
> of the disk latency and this is very bad.
>
> Here are the answer to the alternatives:
> 1) I don't think we do need secure delete but I'm not the one who will make this call but
> If I could, I would turn it off right away as it would remove some stress over the storage
> Systems.
For some folks, this can be a compliance problem. If an organization
is using a cloud provider, then it could be a governance issue too.
See, for example, NIST Special Publication 800-63-1 and the
discussions surrounding zeroization.

Jeff