I am curious about composes.centos.org and it's intended use case or guidance on what it should/can be used for. If it is reasonable, I would like to try to write a dnf plugin to simplify using it for package rollbacks. Is someone else already working on this? Is there a better way to go about doing this?
Ultimately, I would like it so when submitting a bug about a regression, it is easy for the user to specify between what compose dates the regression first appeared.
On Fri, Jun 11, 2021 at 6:56 AM redbaronbrowser via CentOS-devel centos-devel@centos.org wrote:
I am curious about composes.centos.org and it's intended use case or guidance on what it should/can be used for. If it is reasonable, I would like to try to write a dnf plugin to simplify using it for package rollbacks. Is someone else already working on this? Is there a better way to go about doing this?
Ultimately, I would like it so when submitting a bug about a regression, it is easy for the user to specify between what compose dates the regression first appeared.
This shouldn't be necessary since older packages are merged into the repositories now: https://lists.centos.org/pipermail/centos-devel/2021-May/076839.html
The composes are mainly useful for getting older ISOs.
On Friday, June 11th, 2021 at 6:12 AM, Neal Gompa ngompa13@gmail.com wrote:
On Fri, Jun 11, 2021 at 6:56 AM redbaronbrowser via CentOS-devel
centos-devel@centos.org wrote:
I am curious about composes.centos.org and it's intended use case or guidance on what it should/can be used for. If it is reasonable, I would like to try to write a dnf plugin to simplify using it for package rollbacks. Is someone else already working on this? Is there a better way to go about doing this?
Ultimately, I would like it so when submitting a bug about a regression, it is easy for the user to specify between what compose dates the regression first appeared.
This shouldn't be necessary since older packages are merged into the
repositories now:
https://lists.centos.org/pipermail/centos-devel/2021-May/076839.html
The composes are mainly useful for getting older ISOs.
That indicates due to space limitations there may be packages that have only one previous version. 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.
On Fri, Jun 11, 2021 at 7:26 AM redbaronbrowser via CentOS-devel centos-devel@centos.org wrote:
On Friday, June 11th, 2021 at 6:12 AM, Neal Gompa ngompa13@gmail.com wrote:
On Fri, Jun 11, 2021 at 6:56 AM redbaronbrowser via CentOS-devel
centos-devel@centos.org wrote:
I am curious about composes.centos.org and it's intended use case or guidance on what it should/can be used for. If it is reasonable, I would like to try to write a dnf plugin to simplify using it for package rollbacks. Is someone else already working on this? Is there a better way to go about doing this?
Ultimately, I would like it so when submitting a bug about a regression, it is easy for the user to specify between what compose dates the regression first appeared.
This shouldn't be necessary since older packages are merged into the
repositories now:
https://lists.centos.org/pipermail/centos-devel/2021-May/076839.html
The composes are mainly useful for getting older ISOs.
That indicates due to space limitations there may be packages that have only one previous version. 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.
Composes may give you that ability, but they are not retained indefinitely. They will be removed after some time for similar space reasons.
If a user would like to retain all versions of packages that are released, they essentially need to create a local repository with all the versions included.
josh
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
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 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.
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
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
-
Carl George -
Josh Boyer -
Laura Hild -
Neal Gompa -
redbaronbrowser