Open Stack

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
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140312/88082b40/attachment.pgp>