<div dir="ltr">Thanks, will rebase</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 24, 2016 at 1:55 PM, Dan Kenigsberg <span dir="ltr"><<a href="mailto:danken@redhat.com" target="_blank">danken@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, May 24, 2016 at 10:22:16AM +0200, David Caro wrote:<br>
> On 05/24 11:07, Amit Aviram wrote:<br>
> > Hi.<br>
> > For the last day I am getting this error over and over again from jenkins:<br>
> ><br>
> > Start: yum install*07:23:55* ERROR: Command failed. See logs for<br>
> > output.*07:23:55* # /usr/bin/yum-deprecated --installroot<br>
> > /var/lib/mock/epel-7-x86_64-cc6e9a99555654260f7f229c124a6940-31053/root/<br>
> > --releasever 7 install @buildsys-build<br>
> > --setopt=tsflags=nocontexts*07:23:55* WARNING: unable to delete<br>
> > selinux filesystems (/tmp/mock-selinux-plugin.3tk4zgr4): [Errno 1]<br>
> > Operation not permitted: '/tmp/mock-selinux-plugin.3tk4zgr4'*07:23:55*<br>
> > Init took 3 seconds<br>
> ><br>
> ><br>
> > (see <a href="http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/2026/" rel="noreferrer" target="_blank">http://jenkins.ovirt.org/job/vdsm_master_check-patch-el7-x86_64/2026/</a>)<br>
> ><br>
> ><br>
> > This fails the job, so I get -1 from Jenkins CI for my patch.<br>
><br>
><br>
> That's not what's failing the job, is just a warning, the failure is happening<br>
> before that, when installing the chroot:<br>
><br>
> 07:23:53 Start: yum install<br>
> 07:23:55 ERROR: Command failed. See logs for output.<br>
> 07:23:55 # /usr/bin/yum-deprecated --installroot /var/lib/mock/epel-7-x86_64-cc6e9a99555654260f7f229c124a6940-31053/root/ --releasever 7 install @buildsys-build --setopt=tsflags=nocontexts<br>
><br>
> Checking the logs (logs.tgz file, archived on the job, under<br>
> vdsm/logs/mocker-epel-7-x86_64.el7.init/root.log):<br>
><br>
><br>
> DEBUG util.py:417: <a href="https://repos.fedorapeople.org/repos/openstack/openstack-kilo/el7/repodata/repomd.xml" rel="noreferrer" target="_blank">https://repos.fedorapeople.org/repos/openstack/openstack-kilo/el7/repodata/repomd.xml</a>: [Errno 14] HTTPS Error 404 - Not Found<br>
> DEBUG util.py:417: Trying other mirror.<br>
> DEBUG util.py:417: One of the configured repositories failed ("Custom openstack-kilo"),<br>
> DEBUG util.py:417: and yum doesn't have enough cached data to continue. At this point the only<br>
> DEBUG util.py:417: safe thing yum can do is fail. There are a few ways to work "fix" this:<br>
> DEBUG util.py:417: 1. Contact the upstream for the repository and get them to fix the problem.<br>
> DEBUG util.py:417: 2. Reconfigure the baseurl/etc. for the repository, to point to a working<br>
> DEBUG util.py:417: upstream. This is most often useful if you are using a newer<br>
> DEBUG util.py:417: distribution release than is supported by the repository (and the<br>
> DEBUG util.py:417: packages for the previous distribution release still work).<br>
> DEBUG util.py:417: 3. Disable the repository, so yum won't use it by default. Yum will then<br>
> DEBUG util.py:417: just ignore the repository until you permanently enable it again or use<br>
> DEBUG util.py:417: --enablerepo for temporary usage:<br>
> DEBUG util.py:417: yum-config-manager --disable openstack-kilo<br>
> DEBUG util.py:417: 4. Configure the failing repository to be skipped, if it is unavailable.<br>
> DEBUG util.py:417: Note that yum will try to contact the repo. when it runs most commands,<br>
> DEBUG util.py:417: so will have to try and fail each time (and thus. yum will be be much<br>
> DEBUG util.py:417: slower). If it is a very temporary problem though, this is often a nice<br>
> DEBUG util.py:417: compromise:<br>
> DEBUG util.py:417: yum-config-manager --save --setopt=openstack-kilo.skip_if_unavailable=true<br>
> DEBUG util.py:417: failure: repodata/repomd.xml from openstack-kilo: [Errno 256] No more mirrors to try.<br>
><br>
><br>
> So it seems that the repo does not exist anymore, there's a README.txt file<br>
> though that says:<br>
><br>
> RDO Kilo is hosted in CentOS Cloud SIG repository<br>
> <a href="http://mirror.centos.org/centos/7/cloud/x86_64/openstack-kilo/" rel="noreferrer" target="_blank">http://mirror.centos.org/centos/7/cloud/x86_64/openstack-kilo/</a><br>
><br>
> And that new link seems to work ok, so probably you just need to change the<br>
> automation/*.repos files on vdsm git repo to point to the new openstack repos<br>
> url instead of the old one and everything should work ok.<br>
><br>
><br>
><br>
> ><br>
> > I am pretty sure it is not related to the patch. also fc23 job passes.<br>
> ><br>
> ><br>
> > Any idea what's the problem?<br>
<br>
</div></div>Yep, I believe that <a href="https://gerrit.ovirt.org/57870" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/57870</a> has solved that.<br>
Please rebase on top of current ovirt-3.6 branch.<br>
</blockquote></div><br></div>