How to handle "leftover" projects that built in rolling chroots #2933
Comments
|
Let's do the discussion in the next 3 months. |
I had a similar idea but I didn't have time to think it through yet. If I understand correctly, the issue is only with Rawhide chroots. So I was thinking about not marking the project as stale but rather doing something with Rawhide packages that were built many releases ago. For example, Rawhide is currently F40, so considering doing something with Rawhide results from the era when Rawhide was F35 and lower. They will most likely not work today. |
|
@praiskup I guess this is somewhat related to our internal discussion on storage size, correct? If you come up with ideas and if needed, feel free to ping us and brainstorm. We're happy to help if we can. Your team tremendously helped us in the past. |
|
Thank you for the nice words, @kwk, this ticket is related to our discussion "by accident" -> I realized that your team doesn't keep data in stale/useless projects, I just needed to confirm that fact :-) I think the point of this ticket will be to identify such projects or prevent them from occurring. We'll see, your ideas are definitely welcome. |
|
Moving priority to 6 to handle the discussion early. |
|
The proposal for this issue: fedora-copr/debate#8 |
|
In progress - local commit prepared - db migration prepared. |
When rolling policy finishes, we want to remove the data, but we also want to mark the CoprChroot.deleted (disable it from the project) because the corresponding mock chroot is still active in Copr. When user does a new build, we reset the CoprChroot delete_after/notification state, always. This is ok because during the normal MockChroot EOL policy, we do not allow new builds. Implements: https://github.com/fedora-copr/debate/blob/main/2024-04-23-rawhide-chroots-eol.md Fixes: fedora-copr#2933
When rolling policy finishes, we want to remove the data, but we also want to mark the CoprChroot.deleted (disable it from the project) because the corresponding mock chroot is still active in Copr. When user does a new build, we reset the CoprChroot delete_after/notification state, always. This is ok because during the normal MockChroot EOL policy, we do not allow new builds. Implements: https://github.com/fedora-copr/debate/blob/main/2024-04-23-rawhide-chroots-eol.md Fixes: fedora-copr#2933
When rolling policy finishes, we want to remove the data, but we also want to mark the CoprChroot.deleted (disable it from the project) because the corresponding mock chroot is still active in Copr. When user does a new build, we reset the CoprChroot delete_after/notification state, always. This is ok because during the normal MockChroot EOL policy, we do not allow new builds. Implements: https://github.com/fedora-copr/debate/blob/main/2024-04-23-rawhide-chroots-eol.md Fixes: fedora-copr#2933
praiskup
changed the title
When rolling policy finishes, we want to remove the data, but we also want to mark the CoprChroot.deleted (disable it from the project) because the corresponding mock chroot is still active in Copr. When user does a new build, we reset the CoprChroot delete_after/notification state, always. This is ok because during the normal MockChroot EOL policy, we do not allow new builds. Implements: https://github.com/fedora-copr/debate/blob/main/2024-04-23-rawhide-chroots-eol.md Fixes: fedora-copr#2933
When rolling policy finishes, we want to remove the data, but we also want to mark the CoprChroot.deleted (disable it from the project) because the corresponding mock chroot is still active in Copr. When user does a new build, we reset the CoprChroot delete_after/notification state, always. This is ok because during the normal MockChroot EOL policy, we do not allow new builds. Implements: https://github.com/fedora-copr/debate/blob/main/2024-04-23-rawhide-chroots-eol.md Fixes: fedora-copr#2933
When rolling policy finishes, we want to remove the data, but we also want to mark the CoprChroot.deleted (disable it from the project) because the corresponding mock chroot is still active in Copr. When user does a new build, we reset the CoprChroot delete_after/notification state, always. This is ok because during the normal MockChroot EOL policy, we do not allow new builds. Implements: https://github.com/fedora-copr/debate/blob/main/2024-04-23-rawhide-chroots-eol.md Fixes: #2933
The problem with
fedora-rawhide-*chroots is that we never make them EOL. So far there's no automatic removal other storage consumption optimization other than prunerepo that keeps at most one version of each package in one repository.This is not enough; some projects doing mass rebuilds are kept lingering around and consume a nontrivial amount of storage. For example some projects in this 140GB namespace inactive for 2+ years. Some of those projects seem to be created for mass rebuilds, but the user is no longer active in Fedora for us to ask. Well actually asking is a bit sub-optimal for us, it would be better to have some automation.. but dunno.
I'm not inundated with ideas, but could we e.g. take a look at RPMs in the directory, check the "buildtime" baked into RPMs, and if all the RPMs are older than say 2 years mark the project "staled" in DB? I'm not trying to propose a policy for removals right now -> it is a hard decision to remove something when it still might be used by someone. But for us administrators, it is hard to identify such projects to at least start some conversation about possible removals.
The text was updated successfully, but these errors were encountered: