Open Stack

Interesting proposal... there would also be a benefit of different tables per program from an operational perspective. If I need to recover a database for any reason, having different tables would ensure that I could restore glance to a point in time without having to lose the nova delete data.

Tim

From: Mark Washenberger [mailto:mark.washenberger at markwash.net]
Sent: 17 March 2014 21:08
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [db][all] (Proposal) Restorable & Delayed deletion of OS Resources



On Thu, Mar 13, 2014 at 12:42 PM, Boris Pavlovic <bpavlovic at mirantis.com<mailto: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<mailto: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/53de53c1/attachment.html>