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 <cl...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev