On Mon, Apr 11, 2011 at 9:45 AM, Sandy Walsh <email address hidden>wrote:
> Review: Needs Information
> Is the problem with wipe-on-delete that a new instance could use the volume
> before the wipe has completed? If so, shouldn't we be marking the volume as
> "unavailable" until the wipe is completed?
>
No, it is not. Until the wipe is completed, the volume would not be deleted.
(Note though that it appears the currently proposed patch may not do error
handling correctly)
The problem is that to do things this way we would have to:
1) Not use LVM snapshots and make it clear to those deploying Nova that they
cannot use this feature.
2) Make sure the code is tight. It needs to error where it should, fail
where it should, and not leave dangling volumes out there.
This adds complexity and room for bugs to surface. Even if we get it right,
it will not be difficult for someone to make a change that opens a security
hole. That bug might not be in this method.
In my opinion, the core issue is that newly created volumes should be
initialized with zero'ed data. If we need to make sure that new volumes have
zero data, you can only assure this is the case if you're starting from the
the point of creation.
> There should be no real advantage to doing it before or after.
>
Yes, in a perfect world where only Nova touches the volume manager, where
Nova decides to never use snapshots, where Nova has no bugs, and where Nova
developers program with a security-focused mindset. We don't live in a
perfect world.
I say that for Cactus, we put deletion on create and seek to investigate &
implement dm-zero snapshots for the next release.
On Mon, Apr 11, 2011 at 9:45 AM, Sandy Walsh <email address hidden>wrote:
> Review: Needs Information
> Is the problem with wipe-on-delete that a new instance could use the volume
> before the wipe has completed? If so, shouldn't we be marking the volume as
> "unavailable" until the wipe is completed?
>
No, it is not. Until the wipe is completed, the volume would not be deleted.
(Note though that it appears the currently proposed patch may not do error
handling correctly)
The problem is that to do things this way we would have to:
1) Not use LVM snapshots and make it clear to those deploying Nova that they
cannot use this feature.
2) Make sure the code is tight. It needs to error where it should, fail
where it should, and not leave dangling volumes out there.
This adds complexity and room for bugs to surface. Even if we get it right,
it will not be difficult for someone to make a change that opens a security
hole. That bug might not be in this method.
In my opinion, the core issue is that newly created volumes should be
initialized with zero'ed data. If we need to make sure that new volumes have
zero data, you can only assure this is the case if you're starting from the
the point of creation.
> There should be no real advantage to doing it before or after.
>
Yes, in a perfect world where only Nova touches the volume manager, where
Nova decides to never use snapshots, where Nova has no bugs, and where Nova
developers program with a security-focused mindset. We don't live in a
perfect world.
I say that for Cactus, we put deletion on create and seek to investigate &
implement dm-zero snapshots for the next release.
--
Regards,
Eric Windisch