Re: Proposed to delete /mnt/koji/mash/
by Kevin Fenzi
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
6 years
Fedora Release Engineering Meeting Summary for 2018-05-24
by Mohan Boddu
======================================
#fedora-meeting-2: RELENG (2018-05-24)
======================================
Meeting started by mboddu at 16:58:24 UTC. The full logs are available
athttps://meetbot.fedoraproject.org/fedora-meeting-2/2018-05-24/releng.20...
.
Meeting summary
---------------
* init process (mboddu, 16:58:24)
* Alternative Architectures updates (mboddu, 17:03:21)
* F26 will go EOL next Tue and that marks end of s390 koji instance.
sharkcz will work with infra teams in moving the resources to
primary koji (mboddu, 17:14:44)
* Open Floor (mboddu, 17:26:35)
Meeting ended at 17:33:05 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* mboddu (40)
* puiterwijk (27)
* sharkcz (26)
* zodbot (9)
* x3mboy (8)
* linuxmodder (1)
* tyll (0)
* nirik (0)
* masta (0)
* Kellin (0)
* pbrobinson (0)
* dustymabe (0)
* pingou (0)
* maxamillion (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
6 years
[release] pungi 4.1.25
by Lubomír Sedlář
Hello everyone,
a new version of Pungi is available! The 4.1.25 build is ready to be
used. Updates are filed and waiting to get into updates-testing. There
is no longer a build for Fedora 26.
These are the major changes:
* When creating repositories, it's now possible to disable creation of
sqlite databases.
* Module metadata now has correctly filled in arch field.
* Getting list of modules from PDC now supports contexts. All modules
with given (or latest) version will be pulled in.
* Ostree installer is modified to print better error message if copying
the result into compose directory fails.
* It's now also possible to configure the compose to create both
traditional installer and ostree installer in a single variant. Since
these two share the same output location, ostree bits will overwrite
the traditional bits. This is explicitly opt-in.
* Better checking for command line arguments: skipping phases makes
sure the mentioned phase actually exists instead of ignoring such
issues silently.
* If the compose is killed, the status should be updated to TERMINATED
and a message should go out announcing this.
* Pkgset phase has been tweaked a little bit to run more things in
parallel. This should make it somewhat faster.
* There is a long-standing bug that packages that list noarch in
ExclusiveArch do not get properly excluded from repos on non-listed
architectures. Fixing this unconditionally could introduce a lot of
changes, so it is currently hidden behind a configuration option. Users
are encouraged to test this and ideally enable the option.
Refer to the documentation [1] for details on what configuration
options are available.
[1] https://docs.pagure.org/pungi/index.html
If you encounter problems or need general help, stop by #fedora-releng
IRC channel or file issues in Pagure.
Happy composing!
Lubomír
6 years
