[openstack-dev] [Nova][Cinder] Feature about volume delete protection

Huang Zhiteng winston.d at gmail.com
Tue Mar 11 09:37:28 UTC 2014


On Tue, Mar 11, 2014 at 5:09 PM, Zhangleiqiang <zhangleiqiang at huawei.com> wrote:
>> From: Huang Zhiteng [mailto:winston.d at gmail.com]
>> Sent: Tuesday, March 11, 2014 4:29 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Nova][Cinder] Feature about volume delete
>> protection
>>
>> On Tue, Mar 11, 2014 at 11:38 AM, Zhangleiqiang
>> <zhangleiqiang at huawei.com> wrote:
>> > Hi all,
>> >
>> >
>> >
>> > Besides the "soft-delete" state for volumes, I think there is need for
>> > introducing another "fake delete" state for volumes which have snapshot.
>> >
>> >
>> >
>> > Current Openstack refuses the delete request for volumes which have
>> > snapshot. However, we will have no method to limit users to only use
>> > the specific snapshot other than the original volume ,  because the
>> > original volume is always visible for the users.
>> >
>> >
>> >
>> > So I think we can permit users to delete volumes which have snapshots,
>> > and mark the volume as "fake delete" state. When all of the snapshots
>> > of the volume have already deleted, the original volume will be
>> > removed automatically.
>> >
>> Can you describe the actual use case for this?  I not sure I follow why operator
>> would like to limit the owner of the volume to only use specific version of
>> snapshot.  It sounds like you are adding another layer.  If that's the case, the
>> problem should be solved at upper layer instead of Cinder.
>
> For example, one tenant's volume quota is five, and has 5 volumes and 1 snapshot already. If the data in base volume of the snapshot is corrupted, the user will need to create a new volume from the snapshot, but this operation will be failed because there are already 5 volumes, and the original volume cannot be deleted, too.
>
Hmm, how likely is it the snapshot is still sane when the base volume
is corrupted?  Even if this case is possible, I don't see the 'fake
delete' proposal is the right way to solve the problem.  IMO, it
simply violates what quota system is designed for and complicates
quota metrics calculation (there would be actual quota which is only
visible to admin/operator and an end-user facing quota).  Why not
contact operator to bump the upper limit of the volume quota instead?
>> >
>> >
>> >
>> >
>> > Any thoughts? Welcome any advices.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > ----------
>> >
>> > zhangleiqiang
>> >
>> >
>> >
>> > Best Regards
>> >
>> >
>> >
>> > From: John Griffith [mailto:john.griffith at solidfire.com]
>> > Sent: Thursday, March 06, 2014 8:38 PM
>> >
>> >
>> > To: OpenStack Development Mailing List (not for usage questions)
>> > Subject: Re: [openstack-dev] [Nova][Cinder] Feature about volume
>> > delete protection
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Thu, Mar 6, 2014 at 9:13 PM, John Garbutt <john at johngarbutt.com>
>> wrote:
>> >
>> > On 6 March 2014 08:50, zhangyu (AI) <zhangyu11 at huawei.com> wrote:
>> >> It seems to be an interesting idea. In fact, a China-based public
>> >> IaaS, QingCloud, has provided a similar feature to their virtual
>> >> servers. Within 2 hours after a virtual server is deleted, the server
>> >> owner can decide whether or not to cancel this deletion and re-cycle
>> >> that "deleted" virtual server.
>> >>
>> >> People make mistakes, while such a feature helps in urgent cases. Any
>> >> idea here?
>> >
>> > Nova has soft_delete and restore for servers. That sounds similar?
>> >
>> > John
>> >
>> >
>> >>
>> >> -----Original Message-----
>> >> From: Zhangleiqiang [mailto:zhangleiqiang at huawei.com]
>> >> Sent: Thursday, March 06, 2014 2:19 PM
>> >> To: OpenStack Development Mailing List (not for usage questions)
>> >> Subject: [openstack-dev] [Nova][Cinder] Feature about volume delete
>> >> protection
>> >>
>> >> Hi all,
>> >>
>> >> Current openstack provide the delete volume function to the user.
>> >> But it seems there is no any protection for user's delete operation miss.
>> >>
>> >> As we know the data in the volume maybe very important and valuable.
>> >> So it's better to provide a method to the user to avoid the volume
>> >> delete miss.
>> >>
>> >> Such as:
>> >> We can provide a safe delete for the volume.
>> >> User can specify how long the volume will be delay deleted(actually
>> >> deleted) when he deletes the volume.
>> >> Before the volume is actually deleted, user can cancel the delete
>> >> operation and find back the volume.
>> >> After the specified time, the volume will be actually deleted by the
>> >> system.
>> >>
>> >> Any thoughts? Welcome any advices.
>> >>
>> >> Best regards to you.
>> >>
>> >>
>> >> ----------
>> >> zhangleiqiang
>> >>
>> >> Best Regards
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev at lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>
>> >> _______________________________________________
>> >> OpenStack-dev mailing list
>> >> OpenStack-dev at lists.openstack.org
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> > I think a soft-delete for Cinder sounds like a neat idea.  You should
>> > file a BP that we can target for Juno.
>> >
>> >
>> >
>> > Thanks,
>> >
>> > John
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>>
>> --
>> Regards
>> Huang Zhiteng
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Regards
Huang Zhiteng



More information about the OpenStack-dev mailing list