centos job failure with epel-release install

Bug #1728602 reported by YAMAMOTO Takashi
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
networking-midonet
In Progress
Critical
YAMAMOTO Takashi

Bug Description

ipv6 reachability issue?
2604:1580:fe00:0:dead:beef:cafe:fed1 seems like a valid address owned by fedra.

eg. http://logs.openstack.org/77/493377/1/check/legacy-tempest-dsvm-networking-midonet-aio-ml2-full-centos-7/77e1950/logs/devstack-early.txt.gz

+ functions-common:yum_install:1352 : sudo_with_proxies yum install -y epel-release
+ functions-common:sudo_with_proxies:2463 : local sudo
++ functions-common:sudo_with_proxies:2465 : id -u
+ functions-common:sudo_with_proxies:2465 : [[ 1002 = \0 ]]
+ functions-common:sudo_with_proxies:2465 : sudo=sudo
+ functions-common:sudo_with_proxies:2467 : sudo http_proxy= https_proxy= no_proxy= yum install -y epel-release
Loaded plugins: fastestmirror

 One of the configured repositories failed (Unknown),
 and yum doesn't have enough cached data to continue. At this point the only
 safe thing yum can do is fail. There are a few ways to work "fix" this:

     1. Contact the upstream for the repository and get them to fix the problem.

     2. Reconfigure the baseurl/etc. for the repository, to point to a working
        upstream. This is most often useful if you are using a newer
        distribution release than is supported by the repository (and the
        packages for the previous distribution release still work).

     3. Run the command with the repository temporarily disabled
            yum --disablerepo=<repoid> ...

     4. Disable the repository permanently, so yum won't use it by default. Yum
        will then just ignore the repository until you permanently enable it
        again or use --enablerepo for temporary usage:

            yum-config-manager --disable <repoid>
        or
            subscription-manager repos --disable=<repoid>

     5. Configure the failing repository to be skipped, if it is unavailable.
        Note that yum will try to contact the repo. when it runs most commands,
        so will have to try and fail each time (and thus. yum will be be much
        slower). If it is a very temporary problem though, this is often a nice
        compromise:

            yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true

Cannot find a valid baseurl for repo: epel-bootstrap/x86_64
Could not retrieve mirrorlist http://mirrors.fedoraproject.org/mirrorlist?repo=epel-7&arch=x86_64 error was
14: curl#7 - "Failed to connect to 2605:bc80:3010:600:dead:beef:cafe:fed9: Network is unreachable"
+ functions-common:yum_install:1352 : echo YUM_FAILED 1
YUM_FAILED 1
+ functions-common:yum_install:1353 : result=1
+ functions-common:yum_install:1355 : time_stop yum_install
+ functions-common:time_stop:2509 : local name
+ functions-common:time_stop:2510 : local end_time
+ functions-common:time_stop:2511 : local elapsed_time
+ functions-common:time_stop:2512 : local total
+ functions-common:time_stop:2513 : local start_time
+ functions-common:time_stop:2515 : name=yum_install
+ functions-common:time_stop:2516 : start_time=1508918493200
+ functions-common:time_stop:2518 : [[ -z 1508918493200 ]]
++ functions-common:time_stop:2521 : date +%s%3N
+ functions-common:time_stop:2521 : end_time=1508918495001
+ functions-common:time_stop:2522 : elapsed_time=1801
+ functions-common:time_stop:2523 : total=0
+ functions-common:time_stop:2525 : _TIME_START[$name]=
+ functions-common:time_stop:2526 : _TIME_TOTAL[$name]=1801
+ functions-common:yum_install:1364 : '[' 1 == 2 ']'
+ functions-common:yum_install:1368 : return 1
+ ./stack.sh:_install_epel_and_rdo:324 : die 324 'Error installing EPEL repo, cannot continue'
+ functions-common:die:186 : local exitcode=1
+ functions-common:die:187 : set +o xtrace
[Call Trace]
./stack.sh:388:_install_epel_and_rdo
./stack.sh:324:die
[ERROR] ./stack.sh:324 Error installing EPEL repo, cannot continue

Changed in networking-midonet:
assignee: nobody → YAMAMOTO Takashi (yamamoto)
importance: Undecided → Critical
milestone: none → 6.0.0
status: New → In Progress
tags: added: gate-failure midokura-jira-tracked
Revision history for this message
YAMAMOTO Takashi (yamamoto) wrote :

there seems to be no obvious correlation with node_provider etc.

project:"openstack/networking-midonet" AND build_node:"centos-7" AND message:"At completion, logs for this job will be available at"

description: updated
Changed in networking-midonet:
milestone: 6.0.0 → 7.0.0
Changed in networking-midonet:
milestone: 7.0.0 → 8.0.0
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.