We've seen a bunch of yum errors today with our tests. basically a bunch of these types of errors:
[Errno -1] repomd.xml does not match metalink for epel
Full log at [1]. I'm thinking maybe we should modify our tests to run yum in a loop to account for intermittent errors like this?
[1] - https://ci.centos.org/job/atomicapp-test-docker-pr/67/console
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 20/04/16 20:50, Dusty Mabe wrote:
We've seen a bunch of yum errors today with our tests. basically a bunch of these types of errors:
[Errno -1] repomd.xml does not match metalink for epel
Full log at [1]. I'm thinking maybe we should modify our tests to run yum in a loop to account for intermittent errors like this?
[1] - https://ci.centos.org/job/atomicapp-test-docker-pr/67/console
this is actually a problem with fedora infra, EPEL is often broken for direct access.
one option might be to mirror epel into our mirror instance there in the ci network. Would that work Fabian / Brian ?
- -- Karanbir Singh, Project Lead, The CentOS Project +44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS GnuPG Key : http://www.karan.org/publickey.asc
On 21/04/16 14:34, Karanbir Singh wrote:
On 20/04/16 20:50, Dusty Mabe wrote:
We've seen a bunch of yum errors today with our tests. basically a bunch of these types of errors:
[Errno -1] repomd.xml does not match metalink for epel
Full log at [1]. I'm thinking maybe we should modify our tests to run yum in a loop to account for intermittent errors like this?
[1] - https://ci.centos.org/job/atomicapp-test-docker-pr/67/console
this is actually a problem with fedora infra, EPEL is often broken for direct access.
one option might be to mirror epel into our mirror instance there in the ci network. Would that work Fabian / Brian ?
Well, yes and no , but let me explain : - yes for the internal mirror : as soon as we know from where to fetch/rsync pkgs, we can do that and maintain that the same way we have an internal mirror for mirror.centos.org
- no as that would *not* be transparent : by default, when one installs epel-release, the mirrorlist line in /etc/yum.repos.d/epel.repo looks like this : mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch
While we can write a small index.php for an internal mirrorlist node (that's how we redirect all centos yum operations to the internal mirror), we can't cheat with a TLS cert. So we can have an internal mirror, but we'd have to advertize/document it to the CI users so that they'd have to tweak their epel.repo file in their CI jobs to intentionally point to our mirror (so basically replacing the mirrorlist line and have a baseurl one instead) instead of continuing to go to outside.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 21/04/16 13:41, Fabian Arrotin wrote:
On 21/04/16 14:34, Karanbir Singh wrote:
On 20/04/16 20:50, Dusty Mabe wrote:
We've seen a bunch of yum errors today with our tests. basically a bunch of these types of errors:
[Errno -1] repomd.xml does not match metalink for epel
Full log at [1]. I'm thinking maybe we should modify our tests to run yum in a loop to account for intermittent errors like this?
[1] - https://ci.centos.org/job/atomicapp-test-docker-pr/67/console
this is actually a problem with fedora infra, EPEL is often broken for direct access.
one option might be to mirror epel into our mirror instance there in the ci network. Would that work Fabian / Brian ?
Well, yes and no , but let me explain : - yes for the internal mirror : as soon as we know from where to fetch/rsync pkgs, we can do that and maintain that the same way we have an internal mirror for mirror.centos.org
- no as that would *not* be transparent : by default, when one
installs epel-release, the mirrorlist line in /etc/yum.repos.d/epel.repo looks like this : mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch
=$basearch
While we can write a small index.php for an internal mirrorlist node (that's how we redirect all centos yum operations to the internal mirror), we can't cheat with a TLS cert. So we can have an internal mirror, but we'd have to advertize/document it to the CI users so that they'd have to tweak their epel.repo file in their CI jobs to intentionally point to our mirror (so basically replacing the mirrorlist line and have a baseurl one instead) instead of continuing to go to outside.
dont the fedora guys have that mirrormanager redirect option that allows us to map all traffic from our public end points to just return a local url ?
- -- Karanbir Singh, Project Lead, The CentOS Project +44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS GnuPG Key : http://www.karan.org/publickey.asc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Apr 21 13:54, Karanbir Singh wrote:
On 21/04/16 13:41, Fabian Arrotin wrote:
On 21/04/16 14:34, Karanbir Singh wrote:
On 20/04/16 20:50, Dusty Mabe wrote:
We've seen a bunch of yum errors today with our tests. basically a bunch of these types of errors:
[Errno -1] repomd.xml does not match metalink for epel
Full log at [1]. I'm thinking maybe we should modify our tests to run yum in a loop to account for intermittent errors like this?
[1] - https://ci.centos.org/job/atomicapp-test-docker-pr/67/console
this is actually a problem with fedora infra, EPEL is often broken for direct access.
one option might be to mirror epel into our mirror instance there in the ci network. Would that work Fabian / Brian ?
Well, yes and no , but let me explain : - yes for the internal mirror : as soon as we know from where to fetch/rsync pkgs, we can do that and maintain that the same way we have an internal mirror for mirror.centos.org
- no as that would *not* be transparent : by default, when one
installs epel-release, the mirrorlist line in /etc/yum.repos.d/epel.repo looks like this : mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch
=$basearch
While we can write a small index.php for an internal mirrorlist node (that's how we redirect all centos yum operations to the internal mirror), we can't cheat with a TLS cert. So we can have an internal mirror, but we'd have to advertize/document it to the CI users so that they'd have to tweak their epel.repo file in their CI jobs to intentionally point to our mirror (so basically replacing the mirrorlist line and have a baseurl one instead) instead of continuing to go to outside.
dont the fedora guys have that mirrormanager redirect option that allows us to map all traffic from our public end points to just return a local url ?
-- Karanbir Singh, Project Lead, The CentOS Project +44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS GnuPG Key : http://www.karan.org/publickey.asc
I'm pretty sure there are a couple of ways to do that, but I'll check to be sure. +1 for looking into a local EPEL mirror, but I don't think that will solve Dusty's problem here since the problem isn't with the mirror itself but with the metalink hashes which reside entirely in Fedora-managed infrastructure.
- --Brian
On 21/04/16 15:27, Brian Stinson wrote:
I'm pretty sure there are a couple of ways to do that, but I'll check to be sure. +1 for looking into a local EPEL mirror, but I don't think that will solve Dusty's problem here since the problem isn't with the mirror itself but with the metalink hashes which reside entirely in Fedora-managed infrastructure.
Would this still be a problem if the url they hit is all hosted locally ? I would have thought we'd rsync down once a day and gen new repo metadata at the same time. ie. skip the metalink info completely.
On Apr 21 18:43, Karanbir Singh wrote:
On 21/04/16 15:27, Brian Stinson wrote:
I'm pretty sure there are a couple of ways to do that, but I'll check to be sure. +1 for looking into a local EPEL mirror, but I don't think that will solve Dusty's problem here since the problem isn't with the mirror itself but with the metalink hashes which reside entirely in Fedora-managed infrastructure.
Would this still be a problem if the url they hit is all hosted locally ? I would have thought we'd rsync down once a day and gen new repo metadata at the same time. ie. skip the metalink info completely.
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc
Should be doable, the sync will happen regardless. If we skip metalink, then the recommendation would be to set the baseurl in epel.repo which would add an extra step after `yum install epel-release`.
I'm working on testing how to register a private mirror today.
--Brian
On 21/04/16 19:06, Brian Stinson wrote:
Should be doable, the sync will happen regardless. If we skip metalink, then the recommendation would be to set the baseurl in epel.repo which would add an extra step after `yum install epel-release`.
I'm working on testing how to register a private mirror today.
epel access from ci infra is broken again at the moment, did we get anywhere with finding alternatives ?
regards
On Apr 25 14:13, Karanbir Singh wrote:
On 21/04/16 19:06, Brian Stinson wrote:
Should be doable, the sync will happen regardless. If we skip metalink, then the recommendation would be to set the baseurl in epel.repo which would add an extra step after `yum install epel-release`.
I'm working on testing how to register a private mirror today.
epel access from ci infra is broken again at the moment, did we get anywhere with finding alternatives ?
regards
-- Karanbir Singh, Project Lead, The CentOS Project +44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ Ci-users mailing list Ci-users@centos.org https://lists.centos.org/mailman/listinfo/ci-users
We're currently syncing a copy of EPEL to the CI mirror. It should be listed in metalink in the next day or so.
--Brian
The only thing that will mostly (but not entirely) prevent races is for the repo to retain multiple copies of the metadata and the RPMs. The simplest is to do 2.
This would be best done upstream in Fedora of course, but anyone mirroring downstream can do this with `repomanage -k 2` etc.
(OSTree doesn't have this problem by design)
-
Brian Stinson -
Colin Walters -
Dusty Mabe -
Fabian Arrotin -
Karanbir Singh -
Karanbir Singh