Fix prune-database command

This command had two problems:

* It would only delete the first 50 buildsets
* Depending on DB configuration, it may not have deleted anything
  or left orphan data.

We did not tell sqlalchemy to cascade delete operations, meaning that
when we deleted the buildset, we didn't delete anything else.

If the database enforces foreign keys (innodb, psql) then the command
would have failed.  If it doesn't (myisam) then it would have deleted
the buildset rows but not anything else.

The tests use myisam, so they ran without error and without deleting
the builds.  They check that the builds are deleted, but only through
the ORM via a joined load with the buildsets, and since the buildsets
are gone, the builds weren't returned.

To address this shortcoming, the tests now use distinct ORM methods
which return objects without any joins.  This would have caught
the error had it been in place before.

Additionally, the delet operation retained the default limit of 50
rows (set in place for the web UI), meaning that when it did run,
it would only delete the most recent 50 matching builds.

We now explicitly set the limit to a user-configurable batch size
(by default, 10,000 builds) so that we keep transaction sizes
manageable and avoid monopolizing database locks.  We continue deleting
buildsets in batches as long as any matching buildsets remain. This
should allow users to remove very large amounts of data without
affecting ongoing operations too much.

Change-Id: I4c678b294eeda25589b75ab1ce7c5d0b93a07df3

1 files changed, 16 insertions, 0 deletions

diff --git a/releasenotes/notes/fix-prune-database-a4873bd4dead7b5f.yaml b/releasenotes/notes/fix-prune-database-a4873bd4dead7b5f.yaml
new file mode 100644
index 000000000..6e036a754
--- /dev/null
+++ b/releasenotes/notes/fix-prune-database-a4873bd4dead7b5f.yaml
@@ -0,0 +1,16 @@
+---
+fixes:
+  - |
+    The `zuul-admin prune-database` command did not completely delete
+    expected data from the database.  It may not have deleted all of
+    the buildsets older than the specified cutoff time, and it may
+    have left orphaned data in ancillary tables.  This has been
+    corrected and it should now work as expected.  Additionally, a
+    `--batch-size` argument has been added so that it may delete data
+    in multiple transactions which can facilitate smoother operation
+    when run while Zuul is operational.
+
+    Users who have previously run the command may need to manually
+    delete rows from the `zuul_build`, `zuul_build_event`,
+    `zuul_artifact`, and `zuul_provides` tables which do not have
+    corresponding entries in the `zuul_buildset` table.