<div dir="ltr">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 :-).<div>
<br></div><div>-Mike</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 13, 2014 at 1:30 PM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Tim Bell's message of 2014-03-12 11:02:25 -0700:<br>
<div class="">><br>
> ><br>
> > 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<br>
> > 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<br>
> > same could be said with VMs, although likely not all resources, aka networks/.../ make sense to do this.<br>
> ><br>
> > So instead of deleted = 1, wait for cleaner, just save the resource (if<br>
> > possible) + enough metadata on some other system ('backup tape', alternate storage location, hdfs, ceph...) and leave it there unless<br>
> > it's really needed. Making the database more complex (and all associated code) to achieve this same goal seems like a hack that just<br>
> > needs to be addressed with a better way to do archiving.<br>
> ><br>
> > In a cloudy world of course people would be able to recreate everything they need on-demand so who needs undelete anyway ;-)<br>
> ><br>
><br>
> 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.<br>
><br>
> Currently, my understanding is that there is no such function and thus the proposal to remove the deleted column is premature.<br>
><br>
<br>
</div>That seems like an unreasonable request of low level tools like Nova. End<br>
user applications and infrastructure management should be responsible<br>
for these things and will do a much better job of it, as you can work<br>
your own business needs for reliability and recovery speed into an<br>
application aware solution. If Nova does it, your cloud just has to<br>
provide everybody with the same un-delete, which is probably overkill<br>
for _many_ applications.<br>
<div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div>