What do you all do regarding cleanup of old koji tasks? Do you just whack 'em with "find -mtime +N -delete" or is there something more appropriate? I have 120G of livecd spins from my nightly builds and while I have lots of disk space I'm also suspecting that Koji is unconstrained until I do impose my own constraints. True?
Also, perhaps related, can somebody explain to me how the --scratch affects spin-livecd jobs?
-- John Florian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/05/2015 02:07 PM, John Florian wrote:
What do you all do regarding cleanup of old koji tasks? Do you just whack 'em with "find -mtime +N -delete" or is there something more appropriate? I have 120G of livecd spins from my nightly builds and while I have lots of disk space I'm also suspecting that Koji is unconstrained until I do impose my own constraints. True?
Also, perhaps related, can somebody explain to me how the --scratch affects spin-livecd jobs?
-- John Florian
Without --scratch Koji will verify that every RPM that was installed in the image is "known" by the Koji instance. That means either built there, or as part of an external repository associated with a tag. - --scratch images can include RPMs that were built locally or downloaded randomly on the internet.
- --scratch builds are subject to a more aggressive garbage collection policy and are put on a different part of the filesystem to distinguish them. They live in /mnt/koji/scratch.
Without --scratch the provided kickstart file must be from a source control manager too, it cannot be submitted from a local copy.
- - Jay
On 11/05/2015 02:07 PM, John Florian wrote:
<snip>
Also, perhaps related, can somebody explain to me how the --scratch affects spin-livecd jobs?
Without --scratch Koji will verify that every RPM that was installed in the image is "known" by the Koji instance. That means either built there, or as part of an external repository associated with a tag.
- --scratch images can include RPMs that were built locally or
downloaded randomly on the internet.
- --scratch builds are subject to a more aggressive garbage collection
policy and are put on a different part of the filesystem to distinguish them. They live in /mnt/koji/scratch.
Without --scratch the provided kickstart file must be from a source control manager too, it cannot be submitted from a local copy.
- Jay
Jay, thank you for that very detailed answer. That helps my understanding immensely. -- John Florian
On 11/05/2015 02:07 PM, John Florian wrote:
What do you all do regarding cleanup of old koji tasks? Do you just whack ‘em with “find -mtime +N -delete” or is there something more appropriate? I have 120G of livecd spins from my nightly builds and while I have lots of disk space I’m also suspecting that Koji is unconstrained until I do impose my own constraints. True?
I assume you mean the task working dirs under /mnt/koji/work, or perhaps the scratch build outputs under /mnt/koji/scratch. If so the answer (for either) is pretty much. Different koji admins have their own approach. I really should build such cleanup directly into Koji. For now, I recommend just running some cleanup in a cron job.
If you are talking about cleaning up completed builds (non-scratch), then that process is different. For that, you should use the koji-gc tool (generally also run via cron).
https://fedoraproject.org/wiki/Koji/GarbageCollection
Also, perhaps related, can somebody explain to me how the --scratch affects spin-livecd jobs?
--
John Florian
-- buildsys mailing list buildsys@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/buildsys
buildsys@lists.fedoraproject.org
-
Jay Greguske -
John Florian -
Mike McLean