On 08/29/2018 09:19 AM, Randy Barlow wrote:
Fedora 28 will always fail to compose with Bodhi 3.9.0 because of a
recent change that is causing some ostree files to be root owned in
/mnt/koji/compose/updates/[0]. I filed a ticket to ask for help in
deciding a solution to the problem, but we need an immediate solution
because the current compose is marked as failed.
For a short term workaround, I would like to hot patch bodhi-backend01
with this:
diff --git a/bodhi/server/scripts/clean_old_mashes.py
b/bodhi/server/scripts/clean_old_mashes.py
index f812c6d9..e69de3e1 100644
--- a/bodhi/server/scripts/clean_old_mashes.py
+++ b/bodhi/server/scripts/clean_old_mashes.py
@@ -27,7 +27,7 @@ from bodhi.server import config
# How many of the newest mash dirs to keep during cleanup
-NUM_TO_KEEP = 10
+NUM_TO_KEEP = 5
@click.command()
Additionally, I would like to run the above as root on a regular basis
(perhaps daily) until we decide on a proper solution to #7194.
Basically, the current script deletes the most recent 10. This script is
run at the end of the compose and is what is failing. At that point,
there are going to be 11. If I change the script to some number less
than 10 (5 is arbitrary), I can get ahead of what the composer is going
to do and cause it to no-op, which will make it succeed.
This is not a long term solution.
So basically the solution is to run clean_old_mashes.py as root and change
it so that it deletes "more than" what the bodhi run will delete when it runs
as non-root, thus rendering the bodhi run clean_old_mashes.py as a no-op ?
Is the number to keep specified when bodhi calls clean_old_mashes.py or would
it also change to 5 as part of this?
Dusty