Open Stack

On Thu, Mar 13, 2014 at 12:42 PM, Boris Pavlovic <bpavlovic at mirantis.com>wrote:

> Hi stackers,
>
> As a result of discussion:
> [openstack-dev] [all][db][performance] Proposal: Get rid of soft deletion
> (step by step)
> http://osdir.com/ml/openstack-dev/2014-03/msg00947.html
>
> I understood that there should be another proposal. About how we should
> implement Restorable & Delayed Deletion of OpenStack Resource in common way
> & without these hacks with soft deletion in DB.  It is actually very
> simple, take a look at this document:
>
>
> https://docs.google.com/document/d/1WGrIgMtWJqPDyT6PkPeZhNpej2Q9Mwimula8S8lYGV4/edit?usp=sharing
>
>
> Best regards,
> Boris Pavlovic
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>

Hi Boris,

Before I voice a little disagreement, I'd like to thank you for kicking off
this discussion and stress that I strongly agree with your view (pulled
from the other thread)

> To put in a nutshell: Restoring Delete resources / Delayed Deletion !=
Soft deletion.

This is absolutely correct and the key to unlocking the problem we have.

However, because of migrations and because being explicit is better than
being implicit, I disagree about the idea of lumping deleted resources all
into the same table. For glance, I'd much rather have a table
"deleted_images" than a table "deleted_resources" that has some image
entries. There are a number of reasons, I'll try to give a quick high-level
view of them.

1) Migrations for deleted data are more straightforward and more obviously
necessary.
2) It is possible to make specific modifications to the "deleted_X" schema.
3) It is possible to take many tables that are used to represent a single
active resource (images, image_locations, image_tags, image_properties) and
combine them into a single table for a deleted resource. This is actually
super important as today we have the problem of not always knowing what
image_properties were actually deleted prior to the image deletion vs the
ones that were deleted as a part of the image deletion.
4) It makes it a conscious choice to decide to have certain types of
resources restorable or have delayed deletes. As you said before, many
types of resources just don't need this functionality, so let's not make it
a feature of the common base class.

(I am assuming for #2 and #3 that this common approach would be implemented
something like "deleted_resource['data'] =
json.dumps(dict(active_resource))", sorry if that is seriously incorrect.)

Thanks for your consideration,
markwash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140317/36876bdc/attachment.html>