On 05/22/2018 11:43 AM, Mohan Boddu wrote:
> On Sat, May 19, 2018 at 8:43 PM Kevin Fenzi <kevin(a)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.
>>
> I am not sure if any thing still requires them, but if not we can nuke them.
> But do we need backups of this?
I can't think of anything that would be using the updates.
I don't know on the atomic stuff, but I think this is all old and the
new area has all this data already.
>
>>
>> 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?
>>
> We can move them in to their respective directories and we can keep just 14
> days
> of composes around. Container release uses koji to grab the latest base
> container
> but I am not sure who exactly are using Cloud composes.
I think no one currently, but we could use them if they were more
advertised/released. Anyhow, is that something you could take on? Move
them to dirs and prune all but the last 14 days. I think we are all in
agreement on those.
>>
>> 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?
>>
> They are needed as they are being used for calculating static deltas. But
> if needed
> we can remove the failed/unreleased composes inside them (we need to be very
> careful)
Well, they were being used for that yes, but I am not sure pungi does
that anymore. I think it only deltas against the last set of updates.
But sure, we can just keep these for now.
kevin