Verify upgrade targets.[localhost] Check latest available OpenShift RPM version

[bparees]

{
    'package_found': False,
    'returncode': 1,
    'stdout': 'Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=x86_64 error was 
               No timestamp for file',
    'cmd': '/usr/bin/repoquery --plugins --quiet --pkgnarrow=repos --queryformat=%{version}|%{release}|%{arch}|%{repo}|%{version}-%{release} --config=/tmp/tmp9Yegvi origin',
    'results': {},
    'stderr': 'Repository centos-openshift-origin is listed more than once in the configuration
               Repository centos-openshift-origin-testing is listed more than once in the configuration
               Repository centos-openshift-origin-debuginfo is listed more than once in the configuration
               Repository centos-openshift-origin-source is listed more than once in the configuration
               File /var/cache/yum/x86_64/7Server/epel/metalink.xml does not exist'
}

https://ci.openshift.redhat.com/jenkins/job/test_pull_request_origin_extended_conformance_install_update/1448

[sdodson]

The installer doesn't use the epel repo and I think that's the repo that most often creates these problems.

However, we could loop through creating the yum cache a few times and then ensure that all repo interactions only rely on the cache. However the nature of the mirroring system is that it's sticky so you'll likely get the same bad mirror again and my experience is that these sort of errors tend to last 15 minutes to an hour so I don't think we want to wait indefinitely for the mirror to settle.

@stevekuznetsov what do you think we should do here?

[stevekuznetsov]

Hmm... maybe we should just disable EPEL before testing. Let me try that out.

[brenton]

@stevekuznetsov curious if you were able to try removing EPEL?

[stevekuznetsov]

No, have not had time to do that. Looks like we haven't hit this since, though

[arroadie]

facing the same issue on CentOS Linux release 7.3.1611 (Core) trying to install Openshift

[fredrikaverpil]

@arroadie I think something just broke with epel ... as I just came here via google, suddenly experiencing something similar when attempting a simple yum install epel-release.

[arroadie]

and that's why we can't have nice things. Thanks @fredrikaverpil

[luccacabra]

Pretty sure this is an epel error - I'm seeing the same error on a centos VM

sudo yum install vim
Loaded plugins: fastestmirror
epel/x86_64/metalink                                                                                                                                                                     |  12 kB  00:00:00
Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=x86_64 error was
No timestamp for file

And disabling epel allows functionality again

sudo yum --disablerepo="epel" install vim
Loaded plugins: fastestmirror
base                                                                                                                                                                                     | 3.6 kB  00:00:00
extras                                                                                                                                                                                   | 3.4 kB  00:00:00
updates                                                                                                                                                                                  | 3.4 kB  00:00:00
Loading mirror speeds from cached hostfile
...

[fdr]

Seeing this on Amazon Linux from EC2 too, for https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=x86_64 (unrelated to openshift, but where does one report this bug? Figured the Redhat-people might know)

[arroadie]

Looks like it's fixed @fdr @jessicalucci @fredrikaverpil

[dmage]

https://ci.openshift.redhat.com/jenkins/job/test_pull_request_origin_extended_conformance_install_update/3773/testReport/junit/(root)/Verify%20upgrade%20targets/_localhost__Check_latest_available_OpenShift_RPM_version/
The message is different, but the same component.

[arroadie]

yeah @dmage , you may want to try that again in a couple hours. From what I read epel is updated with rsync and sometimes it fails to propagate leaving that as result.

[sdodson]

epel repo has been removed so I believe this particular yum failure should never happen again. Right @stevekuznetsov

[stevekuznetsov]

Heck yeah

[stevekuznetsov]

Actually no, it can happen during image builds as we turn on epel-release in our base image.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[stevekuznetsov]

I think we've squashed this bad boy.

/close