<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 21, 2015 at 2:42 PM, Artom Lifshitz <span dir="ltr"><<a href="mailto:alifshit@redhat.com" target="_blank">alifshit@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I'd like to gauge acceptance of introducing a feature that would give operators<br>
a config option to perform real database deletes instead of soft deletes.<br>
<br>
There's definitely a need for *something* that cleans up the database. There<br>
have been a few attempts at a DB purge engine [1][2][3][4][5], and archiving to<br>
shadow tables has been merged [6] (though that currently has some issues [7]).<br>
<br>
DB archiving notwithstanding, the general response to operators when they<br>
mention the database becoming too big seems to be "DIY cleanup."<br>
<br>
I would like to propose a different approach: add a config option that turns<br>
soft-deletes into real deletes, and start telling operators "if you turn this<br>
on, it's DIY backups."<br>
<br>
Would something like that be acceptable and feasible? I'm ready to put in the<br>
work to implement this, however searching the mailing list indicates that it<br>
would be somewhere between non trivial and impossible [8]. Before I start, I<br>
would like some confidence that it's closer to the former than the latter :)<br></blockquote><div><br></div><div>Acceptable as a deployer option: Yes</div><div>Feasible for all tables: Maybe.  The first steps would be:</div><div><br></div><div>1) Make a list of all the times we read soft deleted data and note which tables they impact.</div><div>2) Determine if making soft delete optional on the tables impacted by read_deleted=True, is useful. If so that would be a an easy win.</div><div>3) Figure out how to remove the read_deleted=True where used.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers!<br>
<br>
[1] <a href="https://blueprints.launchpad.net/nova/+spec/db-purge-engine" target="_blank">https://blueprints.launchpad.net/nova/+spec/db-purge-engine</a><br>
[2] <a href="https://blueprints.launchpad.net/nova/+spec/db-purge2" target="_blank">https://blueprints.launchpad.net/nova/+spec/db-purge2</a><br>
[3] <a href="https://blueprints.launchpad.net/nova/+spec/remove-db-archiving" target="_blank">https://blueprints.launchpad.net/nova/+spec/remove-db-archiving</a><br>
[4] <a href="https://blueprints.launchpad.net/nova/+spec/database-purge" target="_blank">https://blueprints.launchpad.net/nova/+spec/database-purge</a><br>
[5] <a href="https://blueprints.launchpad.net/nova/+spec/db-archiving" target="_blank">https://blueprints.launchpad.net/nova/+spec/db-archiving</a><br>
[6] <a href="https://review.openstack.org/#/c/18493/" target="_blank">https://review.openstack.org/#/c/18493/</a><br>
[7] <a href="https://review.openstack.org/#/c/109201/" target="_blank">https://review.openstack.org/#/c/109201/</a><br>
[8] <a href="http://lists.openstack.org/pipermail/openstack-operators/2014-November/005591.html" target="_blank">http://lists.openstack.org/pipermail/openstack-operators/2014-November/005591.html</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>