[CentOS-devel] Purpose of composes.centso.org?

Josh Boyer

jwboyer at redhat.com
Fri Jun 11 17:20:33 UTC 2021


On Fri, Jun 11, 2021 at 12:23 PM Carl George <carl at 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 at 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 at centos.org
> > https://lists.centos.org/mailman/listinfo/centos-devel
> >
>
>
> --
> Carl George
>
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel


More information about the CentOS-devel mailing list