#8454 How do we make sure signed packages don't get garbage collected?
Closed: Fixed by mohanboddu. Opened by dustymabe.

The coreos-pool koji tag distrepo task just failed with:

Some rpm files were missing.
Most likely, you want to create these signed copies.
Missing files:
/mnt/koji/packages/kernel/5.1.5/300.fc30/data/signed/cfc659b9/x86_64/kernel-5.1.5-300.fc30.x86_64.rpm
/mnt/koji/packages/kernel/5.1.5/300.fc30/data/signed/cfc659b9/x86_64/kernel-core-5.1.5-300.fc30.x86_64.rpm
/mnt/koji/packages/kernel/5.1.5/300.fc30/data/signed/cfc659b9/x86_64/kernel-debug-5.1.5-300.fc30.x86_64.rpm
/mnt/koji/packages/kernel/5.1.5/300.fc30/data/signed/cfc659b9/x86_64/kernel-debug-core-5.1.5-300.fc30.x86_64.rpm
/mnt/koji/packages/kernel/5.1.5/300.fc30/data/signed/cfc659b9/x86_64/kernel-debug-debuginfo-5.1.5-300.fc30.x86_64.rpm
/mnt/koji/packages/kernel/5.1.5/300.fc30/data/signed/cfc659b9/x86_64/kernel-debug-devel-5.1.5-300.fc30.x86_64.rpm
/mnt/koji/packages/kernel/5.1.5/300.fc30/data/signed/cfc659b9/x86_64/kernel-debug-modules-5.1.5-300.fc30.x86_64.rpm
/mnt/koji/packages/kernel/5.1.5/300.fc30/data/signed/cfc659b9/x86_64/kernel-debug-modules-extra-5.1.5-300.fc30.x86_64.rpm
/mnt/koji/packages/kernel/5.1.5/300.fc30/data/signed/cfc659b9/x86_64/kernel-debuginfo-5.1.5-300.fc30.x86_64.rpm
/mnt/koji/packages/kernel/5.1.5/300.fc30/data/signed/cfc659b9/x86_64/kernel-debuginfo-common-x86_64-5.1.5-300.fc30.x86_64.rpm
/mnt/koji/packages/kernel/5.1.5/300.fc30/data/signed/cfc659b9/x86_64/kernel-devel-5.1.5-300.fc30.x86_64.rpm
/mnt/koji/packages/kernel/5.1.5/300.fc30/data/signed/cfc659b9/x86_64/kernel-modules-5.1.5-300.fc30.x86_64.rpm
/mnt/koji/packages/kernel/5.1.5/300.fc30/data/signed/cfc659b9/x86_64/kernel-modules-extra-5.1.5-300.fc30.x86_64.rpm

How do we prevent garbage collection activies like this from happening to packages we care about?


It looks like part of an answer is in this comment where @kevin explains:

  • This is due to us keeping all the versions in the infra-tags repos, not just the latest and them being cleaned up by a prune cron job (that only keeps the latest one in each tag).

He goes on to say:

  • I've set it up to now not prune signed copies in any of the active infra tags, this should prevent it from happening again.

Can we do the same thing for our coreos tags? Also can I know what actual config change is made so that i can propose the patch myself next time?

This commit should fix the issue.

Metadata Update from @mohanboddu:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

Metadata