It appears that kojid is not cleaning up any of the bootstrap repos generated by mock's bootstrap chroot abilities.
How are you using bootstrap caps? We're not supporting it at all for now (it is more a future RFE).
Metadata Update from @tkopecek: - Custom field Size adjusted to None
My koji builders are EL7, but I'm building Fedora and EPEL8 packages.
I'm just setting config_opts['use_bootstrap_container'] = True in site-defaults.
config_opts['use_bootstrap_container'] = True
With Mock v2 using bootstrap containers by default this is probably a bit more interesting....
Metadata Update from @tkopecek: - Issue set to the milestone: 1.22
Yep, looks we will not evade this bullet :-)
We are hitting this issue in production. Over the past week we've filled up our drive three times. Twice after growing it to 250G.
Is there any production workarounds until this issue is resolved?
@praiskup Is there some mock option, which deletes the bootstrap data?
I was able to work-around it by adding: config_opts['use_bootstrap'] = False to my /etc/mock/site-defaults.cfg.
Only command-line option, mock --scrub bootstrap.
mock --scrub bootstrap
I mean, bootstrap is sort of cache - when cleanup is requested, it takes non-trivial time to reinitialize it in the next mock command. So it should be cleaned only when really needed. Since it wastes a lot of space for you, I suppose you are using something like --uniqueext? There's an upstream question which I'm not sure about ATM.
--uniqueext
@praiskup - separate bootstrap dir is created for every build in koji (as separete buildroot per task is created), so space is easily exhausted.
And one more question: Can I expect, that boostrap dir is always /mock_dir/buildroot-bootstrap if /mock_dir/buildroot is buildroot directory?
/mock_dir/buildroot-bootstrap
/mock_dir/buildroot
separete buildroot per task is created
How do you clean the normal buildroot then? Using --scrub=all would work for you (cleans everything, including bootstrap, and dnf caches).
--scrub=all
Can I expect, that boostrap dir is always /mock_dir/buildroot-bootstrap if /mock_dir/buildroot is buildroot directory?
yes
@praiskup There is more complicated policy for that. If build is successful, then after two minutes we delete contents of rootdir. After another 24 hours we delete rootdir itself + mock config. There are some issues with hanging processes and interaction with rpmlib. For failed buildroots there is more complicated policy to have them long enough for debugging. So, it is being done manually outside of mock.
Anyway, at least final step can be done via mock scrub=all + deleting config.
mock scrub=all
Related code starts here: https://pagure.io/koji/blob/master/f/koji/daemon.py#_727
There are some issues with hanging processes and interaction with rpmlib.
This will be fixed in mock v2.2, merged just today. Well, hanging processes were killed by mock for some time - but only those processes that were started by rpmbuild process (not those started by packages' scriptlets from rpm --root -i process).
rpm --root -i
For failed buildroots there is more complicated policy
Ok, in this case you indeed want --scrub bootstrap.
--scrub bootstrap
Nevermind, if you miss some functionality/tweak/fix that would help brewkoji here, fill RFE.
PR #2212
Metadata Update from @jcupova: - Issue tagged with: testing-ready
Metadata Update from @mfilip: - Issue tagged with: testing-done
@tkopecek I'm curious if we can rely on mock's clean/scrub behavior totally in koji
mock
Yes, but not for the version in epel6. When we drop rhel6 support we can drop also this complicated cleaning code.
Commit 9e4148e6 fixes this issue
Commit 2b930de2 fixes this issue
Metadata Update from @julian8628: - Issue status updated to: Open (was: Closed)
a trivial follow-up fix: #2372
Metadata Update from @julian8628: - Issue untagged with: testing-done
Metadata Update from @jcupova: - Issue tagged with: testing-done
Commit a04f6413 fixes this issue
Commit 54f047fc fixes this issue
This issue has been migrated to Fedora Forge: https://forge.fedoraproject.org/koji/koji/issues/1988
Please continue any further discussion there.