On Fri, Jun 11, 2021 at 12:23 PM Carl George carl@redhat.com wrote:
We don't know what our runway on disk space will be either. Hardlinking helps lots but also makes estimating harder. Since announcing that change, we haven't removed any packages for space constraints.
Honestly I question the value of writing a dnf plugin to pick packages out of the old composes, because I expect most if not all package versions will be kept going forward. The space constraint comment was
You may want to consider the impact to mirrors and come up with a retention policy that helps them a bit. We've built 313 kernel packages so far in RHEL 8 (actually more, but at least 313 starting from 4.18.0). Using an "all versions" approach and some very very basic math, that's ~330MB of binary packages per architecture per kernel SRPM, so 1.3G per kernel build * 313 builds ~= 403GB just for the kernels, not including sources or debuginfo.
That's a lot of data for the mirrors to keep around for relatively little gain.
mainly me setting expectations that if we do happen to run out of space, we reserve the right to remove the oldest content to reclaim space. As a practical example, let's say you notice a regression in a kernel update, and we're shipping 10 kernel package versions. What is the likelihood you will need the 10th oldest kernel to verify when the regression happened? Unless you've gone a long time without updating, having the last 2 or 3 kernels is probably sufficient.
Right. I'd suggest defining a policy that is approximately N-5 versions and adjust from there if needed.
josh
On Fri, Jun 11, 2021 at 10:06 AM Laura Hild lsh@jlab.org wrote:
I was looking to be able to go back more than one version and it seem like composes could allow doing that? Not all issues are discovered right away and may already exist in the previous version.
I did this just yesterday, going back to systemd-239-43. I noticed my problem on RHEL, which jumped from 41 to 45, but I am potentially able to write a better ticket by being able to reproduce it in Stream, if I can go back more than one version.
Could it make sense to base what versions are made available in Stream on what's between versions in RHEL? I have no concept of the limits on space though, particularly for mirrors.
-Laura
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
-- Carl George
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel