Hi all SIG members,
When working in our "Staging" environment while validating the new signing process (still to be announced when fully in use/prod), we detected some SIGs having multiple variants/versions of their packages.
Just one example (already discussed with Niels and Kaleb in #centos-devel but let's just this one a example): Gluster has multiple versions still listed on mirror.centos.org : http://mirror.centos.org/centos/7/storage/x86_64/
As the new process would automatically decide where to push content based on koji/cbs tag name, we found the interesting corner case of gluster312. The CBS tag is storage7-gluster-312-release and so new process would push to centos/7/storage/x86_64/gluster-312/ instead of http://mirror.centos.org/centos/7/storage/x86_64/gluster-3.12/ (see the diff betwen koji/cbs tag and the final path/destination)
It seems that only Gluster was impacted for older releases, while it should be good for new releases (tested).
But so that brings the following request : can you come with a list of EOL repositories that you'd like us to trim/remove from mirror.centos.org (they'll be archived to vault.centos.org) ? Doing that at the same time as we launch the new signing/push process would be a good idea.
Thanks a lot in advance for your collaboration !
Il giorno gio 12 mar 2020 alle ore 15:01 Fabian Arrotin arrfab@centos.org ha scritto:
Hi all SIG members,
When working in our "Staging" environment while validating the new signing process (still to be announced when fully in use/prod), we detected some SIGs having multiple variants/versions of their packages.
Just one example (already discussed with Niels and Kaleb in #centos-devel but let's just this one a example): Gluster has multiple versions still listed on mirror.centos.org : http://mirror.centos.org/centos/7/storage/x86_64/
As the new process would automatically decide where to push content based on koji/cbs tag name, we found the interesting corner case of gluster312. The CBS tag is storage7-gluster-312-release and so new process would push to centos/7/storage/x86_64/gluster-312/ instead of http://mirror.centos.org/centos/7/storage/x86_64/gluster-3.12/ (see the diff betwen koji/cbs tag and the final path/destination)
It seems that only Gluster was impacted for older releases, while it should be good for new releases (tested).
But so that brings the following request : can you come with a list of EOL repositories that you'd like us to trim/remove from mirror.centos.org (they'll be archived to vault.centos.org) ? Doing that at the same time as we launch the new signing/push process would be a good idea.
Thanks a lot in advance for your collaboration !
For oVirt, you can move to vault: http://mirror.centos.org/centos/7/virt/x86_64/ovirt-4.2/ since oVirt 4.2 reached EOL around one year ago and is not compatible with CentOS 7.7 and http://mirror.centos.org/centos/7/virt/x86_64/ovirt-4.4/ since upstream decided to drop el7 support for oVIrt 4.4 and have it el8 only.
-- Fabian Arrotin The CentOS Project | https://www.centos.org gpg key: 17F3B7A1 | twitter: @arrfab
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 12/03/2020 15:18, Sandro Bonazzola wrote:
Il giorno gio 12 mar 2020 alle ore 15:01 Fabian Arrotin <arrfab@centos.org mailto:arrfab@centos.org> ha scritto:
<snip>
For oVirt, you can move to vault: http://mirror.centos.org/centos/7/virt/x86_64/ovirt-4.2/ since oVirt 4.2 reached EOL around one year ago and is not compatible with CentOS 7.7 and http://mirror.centos.org/centos/7/virt/x86_64/ovirt-4.4/ since upstream decided to drop el7 support for oVIrt 4.4 and have it el8 only.
Thanks a lot Sandro for the answer. I'll note those two to be removed when we'll switch to new process, but ideally you (as SIG) would probably have to announce that somewhere ? That's still something we'd need to properly figure out : how and where to announce deprecated content being removed (as people don't always follow mailing-lists, announces, etc and then come back on either irc or forums to complain that pkgs disappeared, even if EOL, etc)
On Thu, Mar 12, 2020 at 03:18:29PM +0100, Sandro Bonazzola wrote:
Il giorno gio 12 mar 2020 alle ore 15:01 Fabian Arrotin arrfab@centos.org ha scritto:
Hi all SIG members,
When working in our "Staging" environment while validating the new signing process (still to be announced when fully in use/prod), we detected some SIGs having multiple variants/versions of their packages.
Just one example (already discussed with Niels and Kaleb in #centos-devel but let's just this one a example): Gluster has multiple versions still listed on mirror.centos.org : http://mirror.centos.org/centos/7/storage/x86_64/
As the new process would automatically decide where to push content based on koji/cbs tag name, we found the interesting corner case of gluster312. The CBS tag is storage7-gluster-312-release and so new process would push to centos/7/storage/x86_64/gluster-312/ instead of http://mirror.centos.org/centos/7/storage/x86_64/gluster-3.12/ (see the diff betwen koji/cbs tag and the final path/destination)
It seems that only Gluster was impacted for older releases, while it should be good for new releases (tested).
But so that brings the following request : can you come with a list of EOL repositories that you'd like us to trim/remove from mirror.centos.org (they'll be archived to vault.centos.org) ? Doing that at the same time as we launch the new signing/push process would be a good idea.
Thanks a lot in advance for your collaboration !
For oVirt, you can move to vault: http://mirror.centos.org/centos/7/virt/x86_64/ovirt-4.2/ since oVirt 4.2 reached EOL around one year ago and is not compatible with CentOS 7.7 and http://mirror.centos.org/centos/7/virt/x86_64/ovirt-4.4/ since upstream decided to drop el7 support for oVIrt 4.4 and have it el8 only.
Last time we dropped some centos-release-gluster packages from Extras, but oVirt was still expecting older, unmaintained Gluster versions to be available. What version of Gluster does oVirt consume at the moment?
Ideally we archive/drop all EOL versions. The current maintained versions are on https://www.gluster.org/release-schedule/
Thanks, Niels
Il giorno ven 13 mar 2020 alle ore 11:02 Niels de Vos ndevos@redhat.com ha scritto:
On Thu, Mar 12, 2020 at 03:18:29PM +0100, Sandro Bonazzola wrote:
Il giorno gio 12 mar 2020 alle ore 15:01 Fabian Arrotin <
arrfab@centos.org>
ha scritto:
Hi all SIG members,
When working in our "Staging" environment while validating the new signing process (still to be announced when fully in use/prod), we detected some SIGs having multiple variants/versions of their packages.
Just one example (already discussed with Niels and Kaleb in #centos-devel but let's just this one a example): Gluster has multiple versions still listed on mirror.centos.org : http://mirror.centos.org/centos/7/storage/x86_64/
As the new process would automatically decide where to push content based on koji/cbs tag name, we found the interesting corner case of gluster312. The CBS tag is storage7-gluster-312-release and so new process would push to centos/7/storage/x86_64/gluster-312/ instead of http://mirror.centos.org/centos/7/storage/x86_64/gluster-3.12/ (see
the
diff betwen koji/cbs tag and the final path/destination)
It seems that only Gluster was impacted for older releases, while it should be good for new releases (tested).
But so that brings the following request : can you come with a list of EOL repositories that you'd like us to trim/remove from mirror.centos.org (they'll be archived to vault.centos.org) ? Doing that at the same time as we launch the new signing/push process would be a good idea.
Thanks a lot in advance for your collaboration !
For oVirt, you can move to vault: http://mirror.centos.org/centos/7/virt/x86_64/ovirt-4.2/ since oVirt 4.2 reached EOL around one year ago and is not compatible with CentOS 7.7 and http://mirror.centos.org/centos/7/virt/x86_64/ovirt-4.4/ since upstream decided to drop el7 support for oVIrt 4.4 and have it el8 only.
Last time we dropped some centos-release-gluster packages from Extras, but oVirt was still expecting older, unmaintained Gluster versions to be available. What version of Gluster does oVirt consume at the moment?
Ideally we archive/drop all EOL versions. The current maintained versions are on https://www.gluster.org/release-schedule/
Current supported versions for oVirt are: oVirt 4.3 (stable): requiring GlusterFS 6 oVirt 4.4 (in development): requiring GlusterFS 7
Thanks, Niels
On Fri, Mar 13, 2020 at 11:16:56AM +0100, Sandro Bonazzola wrote:
Il giorno ven 13 mar 2020 alle ore 11:02 Niels de Vos ndevos@redhat.com ha scritto:
On Thu, Mar 12, 2020 at 03:18:29PM +0100, Sandro Bonazzola wrote:
Il giorno gio 12 mar 2020 alle ore 15:01 Fabian Arrotin <
arrfab@centos.org>
ha scritto:
Hi all SIG members,
When working in our "Staging" environment while validating the new signing process (still to be announced when fully in use/prod), we detected some SIGs having multiple variants/versions of their packages.
Just one example (already discussed with Niels and Kaleb in #centos-devel but let's just this one a example): Gluster has multiple versions still listed on mirror.centos.org : http://mirror.centos.org/centos/7/storage/x86_64/
As the new process would automatically decide where to push content based on koji/cbs tag name, we found the interesting corner case of gluster312. The CBS tag is storage7-gluster-312-release and so new process would push to centos/7/storage/x86_64/gluster-312/ instead of http://mirror.centos.org/centos/7/storage/x86_64/gluster-3.12/ (see
the
diff betwen koji/cbs tag and the final path/destination)
It seems that only Gluster was impacted for older releases, while it should be good for new releases (tested).
But so that brings the following request : can you come with a list of EOL repositories that you'd like us to trim/remove from mirror.centos.org (they'll be archived to vault.centos.org) ? Doing that at the same time as we launch the new signing/push process would be a good idea.
Thanks a lot in advance for your collaboration !
For oVirt, you can move to vault: http://mirror.centos.org/centos/7/virt/x86_64/ovirt-4.2/ since oVirt 4.2 reached EOL around one year ago and is not compatible with CentOS 7.7 and http://mirror.centos.org/centos/7/virt/x86_64/ovirt-4.4/ since upstream decided to drop el7 support for oVIrt 4.4 and have it el8 only.
Last time we dropped some centos-release-gluster packages from Extras, but oVirt was still expecting older, unmaintained Gluster versions to be available. What version of Gluster does oVirt consume at the moment?
Ideally we archive/drop all EOL versions. The current maintained versions are on https://www.gluster.org/release-schedule/
Current supported versions for oVirt are: oVirt 4.3 (stable): requiring GlusterFS 6 oVirt 4.4 (in development): requiring GlusterFS 7
Thanks!
From the Gluster project in the Storage SIG, the following repositories
can be removed/archived:
storage/x86_64/gluster-3.12 storage/x86_64/gluster-4.0 storage/x86_64/gluster-4.1
That also means these package need to be removed from Extras:
centos-release-gluster40 centos-release-gluster41
Niels
Hi all, for SCLo SIG purposes, we keep a list of collections at https://github.com/sclorg/sclo-ci-tests, specifically:
https://github.com/sclorg/sclo-ci-tests/blob/master/PackageLists/collections... https://github.com/sclorg/sclo-ci-tests/blob/master/PackageLists/collections...
Any collection in these list marked EOL could be trimmed from the mirrors. The lists may be slightly outdated, but that would only mean some EOL marks could be missing – anything already marked is fair game.
On 3/16/20 6:06 AM, Jan Staněk wrote:
Hi all, for SCLo SIG purposes, we keep a list of collections at https://github.com/sclorg/sclo-ci-tests, specifically:
https://github.com/sclorg/sclo-ci-tests/blob/master/PackageLists/collections... https://github.com/sclorg/sclo-ci-tests/blob/master/PackageLists/collections...
Any collection in these list marked EOL could be trimmed from the mirrors. The lists may be slightly outdated, but that would only mean some EOL marks could be missing – anything already marked is fair game.
We need to make sure nothing else needs the things marked to EOL.
We had issues in the past removing some SCL items that were needed buy other things still active.
When i move things to vault, they are gone from the main mirrors, they will not be available to any project.
We need to make sure nothing else needs the things marked to EOL.
That I would have to check manually – the markers technically only mean that no further update would be published.
In case you want to proceed without waiting on me, follow the koji tag inheritance from cbs-tools repo (scripts/sigs/sclo/sclo-inheritance.sh). If any active collection inherits from EOL one, we would have a problem. Otherwise we *should* be fine (fingers crossed).
I will try to schedule some time this week and take a closer look at this.
On 16/03/2020 16:55, Jan Staněk wrote:
We need to make sure nothing else needs the things marked to EOL.
That I would have to check manually – the markers technically only mean that no further update would be published.
In case you want to proceed without waiting on me, follow the koji tag inheritance from cbs-tools repo (scripts/sigs/sclo/sclo-inheritance.sh). If any active collection inherits from EOL one, we would have a problem. Otherwise we *should* be fine (fingers crossed).
I will try to schedule some time this week and take a closer look at this.
That would be great as we'd like to push that "live" ASAP now, also now that we have the infra in place (including all SIGs keys)
-
Fabian Arrotin -
Jan Staněk -
Johnny Hughes -
Niels de Vos -
Sandro Bonazzola