On 03/11/2014 11:10 PM, Jay Pipes wrote: > On Wed, 2014-03-12 at 01:47 +0000, Joshua Harlow wrote: >> The question that I don't understand is why does this process have to be >> involve the database to begin with? >> >> 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 ;-) > > Good points. > > Another way to ask the question: does Amazon provide an undelete > functionality?
Man, if that was our threshold for doing things, we could delete a ton of OpenStack code. :P Honestly, I think it's important to realize that a very large OpenStack deploy has found undelete *really useful*. Perhaps the current way they are doing it is hacky based on something that wasn't intended, so we should have a more explicit undelete method, however I don't think it's immediately invalid because AWS doesn't do it. Back to the original question, my, limited, understanding is soft delete is there for eventual consistency. It means that everyone doesn't need a current view of the database all the time, and that a bunch of operations don't need to sit under transactions. Like the ability to do a list_images while and image is being deleted, especially given that we denormalize a lot of these things over multiple tables. That, however, may be an out of date concept here. I haven't stayed up on everything in that piece of the stack. -Sean -- Sean Dague Samsung Research America s...@dague.net / sean.da...@samsung.com http://dague.net
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev