Greetings.
/mnt/koji is getting low on space, and one thing I noticed is that we still have:
/mnt/koji/mash/
This is the directory we used to use back when we used mash to push updates. It has in it:
221G atomic 59M atomic-updates 160M atomic-updates-logs 1.3T updates
So, nuking this should save us hopefully about 1.5TB.
Additionally, in /mnt/koji/compose/ we have at least 108 each of:
Fedora-Cloud-26-* Fedora-Docker-26* Fedora-Cloud-27-* Fedora-Docker-27*
How many of those should we keep around?
Also, we have compose dirs for 26, 27, 28 with all the composes we had for each cycle. Do we want to/need to keep those around any? Should we delete them when a release goes EOL?
If anyone sees anything else we are no longer using, please let me know.
Does anyone need/want/see a need for any of the above?
kevin
On Sun, May 20, 2018 at 1:43 AM, Kevin Fenzi kevin@scrye.com wrote:
Greetings.
/mnt/koji is getting low on space, and one thing I noticed is that we still have:
/mnt/koji/mash/
This is the directory we used to use back when we used mash to push updates. It has in it:
221G atomic 59M atomic-updates 160M atomic-updates-logs 1.3T updates
So, nuking this should save us hopefully about 1.5TB.
+1 to this.
Additionally, in /mnt/koji/compose/ we have at least 108 each of:
Fedora-Cloud-26-* Fedora-Docker-26* Fedora-Cloud-27-* Fedora-Docker-27*
These should be moved into a container and cloud sub directory like all the other pungi runs, then the find -mtime +14 can be run on them at the end of each compose like the rest of them. I noticed this some time ago but never got around to filing a ticket/PR to fix it.
How many of those should we keep around?
14 like all the rest of the composes.
Also, we have compose dirs for 26, 27, 28 with all the composes we had for each cycle. Do we want to/need to keep those around any? Should we delete them when a release goes EOL?
I think bodhi uses something around this for builds, as I think does the two week atomic, but someone else that knows both of those better than me can likely confirm.
If anyone sees anything else we are no longer using, please let me know.
Does anyone need/want/see a need for any of the above?
Peter
On Sun, 2018-05-20 at 10:32 +0100, Peter Robinson wrote:
Additionally, in /mnt/koji/compose/ we have at least 108 each of:
Fedora-Cloud-26-* Fedora-Docker-26* Fedora-Cloud-27-* Fedora-Docker-27*
These should be moved into a container and cloud sub directory like all the other pungi runs, then the find -mtime +14 can be run on them at the end of each compose like the rest of them. I noticed this some time ago but never got around to filing a ticket/PR to fix it.
Guys, next time you're going to do something like this can you *please* give me a heads up?
Remember I maintain a tool whose entire job is to *know where composes are*, and it's wired into various QA processes; if you're going to move composes around, please let me know before doing it. I woke up today to a flood of traceback mails whose basic cause is that fedfind can't find these composes any more because they got moved without anyone telling me ahead of time.
Now I've got to send out an emergency release to fix it, and moving composes around has a whole knock-on effect because it messes up part of the test suite which uses real-life data (a log of 180 days' worth of 'compose status changed' messages); this is going to be doubly difficult to deal with because by moving finished composes you have *rendered the data in those messages incorrect*. E.g. https://apps.fedoraproject.org/datagrepper/id?id=2018-dccb5b21-9b15-4735-b50... claims the URL for the compose is http://kojipkgs.fedoraproject.org/compose/Fedora-Cloud-27-20180517.0/compose , but if you look there, you won't find it any more. So now I have to do some kind of ugly workaround for that.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 05/19/2018 08:43 PM, Kevin Fenzi wrote:
Greetings.
/mnt/koji is getting low on space, and one thing I noticed is that we still have:
/mnt/koji/mash/
This is the directory we used to use back when we used mash to push updates. It has in it:
221G atomic 59M atomic-updates 160M atomic-updates-logs 1.3T updates
So, nuking this should save us hopefully about 1.5TB.
I'm +1 here. it's all from EOL releases anyway and we moved over to /mnt/koji/compose/atomic/repo/ for new atomic updates composes.
Dusty
rel-eng@lists.fedoraproject.org