Extending CI support to s390x about dns HOT 12 CLOSED

Do the e2e test scripts not work if the right container images are used?

from dns.

@bowei Thanks for above information. I am trying to port the container images required in e2e testing, this activity currently in progress. Can you please let me know how e2e testing is used in CI.

from dns.

Hi @bowei,
When I try to run e2e script the build to create sidecar-e2e container is failing on step
RUN apk update && apk install curl bind-tools
as apk is not available in s390x/busybox:glibc image from which gcr.io/google_containers/k8s-dns-dnsmasq-s390x:1.14.2 is build. To overcome this I tried to build gcr.io/google_containers/k8s-dns-dnsmasq-s390x:1.14.2-dirty image on x86 for s390x from an alpine image with tmh1999/alpine-s390x as base image, with this docker image also it says apk: not found.

Later tried to build dnsmasq image with s390x/Ubuntu:16.04 on x86 as base image but build was failing.

Any pointers on resolving this issue would be very helpful. Thanks in advance.

from dns.

The e2e test uses curl and dig, so you will need to build an e2e image for s390 based on a linux userland that has those tools. For example, you could build an image (and host on dockerhub) with those tools already installed and change the base image for s390 e2e to use that base image.

from dns.

I uploaded an image (garydocker/s390x-ubuntu-net:16.04) on docker hub having dig, curl and build the dnsmasq (gcr.io/google_containers/k8s-dns-dnsmasq-s390x:1.14.3-dirty) and other associated images on x86 for s390x. Later on s390x, I loaded and retagged the dnsmasq-s390x image and referred it in docker.e2e for sidecar e2e test, I also copied the required s390x's sidecar and sidecar-e2e binaries on s390x host from x86 host and updated the docker file accordingly to refer to these binaries for copying. But still the e2e testcase for sidecar is failing, updating logs for reference:

$./build/e2e-test.sh
-------
sidecar
-------
2017/06/22 01:24:03 opts={mode:harness cleanup:false baseDir:. dockerfile:Dockerfile.e2e dnsmasqBinary:/usr/sbin/dnsmasq sidecarBinary:/sidecar digBinary:/usr/bin/dig outputDir:/test}
2017/06/22 01:24:03 Running as harness (tmpdir = /tmp/k8s-dns-sidecar-e2e984409347)
2017/06/22 01:24:03 docker [build -f ./test/e2e/sidecar/Dockerfile.e2e -t k8s-dns-sidecar-e2e-test .]
2017/06/22 01:24:33 docker [run --rm=true -v /tmp/k8s-dns-sidecar-e2e984409347:/test k8s-dns-sidecar-e2e-test]
2017/06/22 01:24:46 test | 2017/06/22 05:24:33 opts={mode:test cleanup:false baseDir:. dockerfile:Dockerfile.e2e dnsmasqBinary:/usr/sbin/dnsmasq sidecarBinary:/sidecar digBinary:/usr/bin/dig outputDir:/test}
2017/06/22 01:24:46 test | 2017/06/22 05:24:33 Running as test
2017/06/22 01:24:46 test | 2017/06/22 05:24:33 Starting dnsmasq [-q -k -a 127.0.0.1 -p 10053 -c 1337 -8 - -A /ok.local/1.2.3.4 -A /nxdomain.local/]
2017/06/22 01:24:46 test | 2017/06/22 05:24:34 dnsmasq started
2017/06/22 01:24:46 test | 2017/06/22 05:24:34 Starting sidecar [-v 4 --prometheus-port 10054 --dnsmasq-port 10053 --probe ok,127.0.0.1:10053,ok.local,1 --probe nxdomain,127.0.0.1:10053,nx.local,1 --probe notpresent,127.0.0.1:10054,notpresent.local,1]
2017/06/22 01:24:46 test | 2017/06/22 05:24:35 sidecar started
2017/06/22 01:24:46 test | 2017/06/22 05:24:35 running `dig`
2017/06/22 01:24:46 test | 2017/06/22 05:24:35 Waiting for hits to be reported to be greater than 100
2017/06/22 01:24:46 test |
2017/06/22 01:24:46 Tests failed
2017/06/22 01:24:46 error | expected kubedns_dnsmasq_hits > 100 but got 20
2017/06/22 01:24:46 docker [rmi -f k8s-dns-sidecar-e2e-test]

Could you please highlight if I am still missing onto something. I also compared the above test logs with x86 logs and could not see any differences till final test result is displayed. Currently I am checking if I can enable more debug logs from test.
Thanks in advance.

from dns.

hi @bowei , from the README doc I came to know that Travis CI is being used in the CI setup for Kube-dns. Currently Travis CI is not supported on s390x. Could you kindly confirm on your existing CI setup, if it is Travis CI we will not be able to provide CI support for s390x and we can close this request.

from dns.

Travis calls out to the build/e2e-test.sh script, so it is just a way to run the tests online. Can you try increasing the timeout for the dnsmasq test? It might be that the current timeouts are too tight for your environment. See around line 446 in cmd/sidecar-e2e/main.go

from dns.

Thanks for above inputs.

I do understand that Travis calls out build/e2e-test.sh script. But for CI, if Travis is only thing which is present at the backend then we will be not be able to invoke the above script on s390x as Travis is not supported on s390x. We really wanted to extend CI support for s390x but if it is using only Travis then we will have to stop this activity. If CI is possible for s390x without Travis only then we are planning to continue debugging e2e failures.

from dns.

Does the s390x image include a QEMU emulator for the platform? I think that's how some of the other architectures are being tested today...

from dns.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

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

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

from dns.

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

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

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

from dns.

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

from dns.