[openstack-dev] [all][db][performance] Proposal: Get rid of soft deletion (step by step)

Mike Wilson geekinutah at gmail.com
Thu Mar 13 19:41:01 UTC 2014


The restore use case is for sure inconsistently implemented and used. I
think I agree with Boris that we treat it as separate and just move on with
cleaning up soft delete. I imagine most deployments don't like having most
of the rows in their table be useless and make db access slow? That being
said, I am a little sad my hacky restore method will need to be reworked
:-).

-Mike


On Thu, Mar 13, 2014 at 1:30 PM, Clint Byrum <clint at fewbar.com> wrote:

> Excerpts from Tim Bell's message of 2014-03-12 11:02:25 -0700:
> >
> > >
> > > If you want to archive images per-say, on deletion just export it to a
> 'backup tape' (for example) and store enough of the metadata
> > > on that 'tape' to re-insert it if this is really desired and then
> delete it from the database (or do the export... asynchronously). The
> > > same could be said with VMs, although likely not all resources, aka
> networks/.../ make sense to do this.
> > >
> > > So instead of deleted = 1, wait for cleaner, just save the resource (if
> > > possible) + enough metadata on some other system ('backup tape',
> alternate storage location, hdfs, ceph...) and leave it there unless
> > > it's really needed. Making the database more complex (and all
> associated code) to achieve this same goal seems like a hack that just
> > > needs to be addressed with a better way to do archiving.
> > >
> > > In a cloudy world of course people would be able to recreate
> everything they need on-demand so who needs undelete anyway ;-)
> > >
> >
> > I have no problem if there was an existing process integrated into all
> of the OpenStack components which would produce me an archive trail with
> meta data and a command to recover the object from that data.
> >
> > Currently, my understanding is that there is no such function and thus
> the proposal to remove the deleted column is premature.
> >
>
> That seems like an unreasonable request of low level tools like Nova. End
> user applications and infrastructure management should be responsible
> for these things and will do a much better job of it, as you can work
> your own business needs for reliability and recovery speed into an
> application aware solution. If Nova does it, your cloud just has to
> provide everybody with the same un-delete, which is probably overkill
> for _many_ applications.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140313/73fe3e89/attachment.html>


More information about the OpenStack-dev mailing list