Description of problem: Since 3.0.1.0 we have been getting those error when running a S2I the sti-builder cannot simply connect to https:// url github here but really any https:// in general Version-Release number of selected component (if applicable): 3.0.0.1 How reproducible: I am not so sure it shows on a fresh install on amazon for me and on an upgrade as well Steps to Reproduce: 1. oc start-build a sti image with https:// git url Actual results: I0804 16:42:05.153011 1 docker.go:199] Image registry.access.redhat.com/openshift3/python-33-rhel7:latest available locally I0804 16:42:05.162270 1 sti.go:99] Starting S2I build from foo/simple-test-314 BuildConfig ... I0804 16:42:05.162903 1 sti.go:113] Building 172.30.160.37:5000/foo/simple-test:latest I0804 16:42:05.238666 1 clone.go:27] Cloning into /tmp/sti463645757/upload/src E0804 16:42:06.033900 1 git.go:127] fatal: unable to access 'https://github.com/chmouel/simple-dockerfile/': Peer's certificate issuer has been marked as not trusted by the user. Expected results: Build Additional info: I have tried to git clone directly on the sti-builder image and it works, I can't find a way to properly debug that
I can not reproduce this issue on 3.0.1.0 installation. $ oc new-app https://github.com/chmouel/simple-dockerfile.git -i openshift/python $ oc start-build simple-dockerfile simple-dockerfile-1 $ oc build-logs simple-dockerfile-1 <--snip--> I0805 02:30:37.747892 1 docker.go:199] Image registry.access.redhat.com/openshift3/python-33-rhel7:latest available locally I0805 02:30:37.781727 1 sti.go:99] Starting S2I build from jialiu/simple-dockerfile-1 BuildConfig ... I0805 02:30:37.781778 1 sti.go:113] Building 172.30.164.136:5000/jialiu/simple-dockerfile:latest I0805 02:30:37.789926 1 clone.go:27] Cloning into /tmp/sti049201203/upload/src I0805 02:30:54.635299 1 docker.go:199] Image registry.access.redhat.com/openshift3/python-33-rhel7:latest available locally I0805 02:30:54.635443 1 docker.go:305] Image contains io.openshift.s2i.scripts-url set to 'image:///usr/local/sti' I0805 02:30:54.635479 1 download.go:57] Using image internal scripts from: image:///usr/local/sti/assemble I0805 02:30:54.635914 1 download.go:57] Using image internal scripts from: image:///usr/local/sti/run I0805 02:30:54.642127 1 docker.go:199] Image registry.access.redhat.com/openshift3/python-33-rhel7:latest available locally I0805 02:30:54.642147 1 docker.go:305] Image contains io.openshift.s2i.scripts-url set to 'image:///usr/local/sti' I0805 02:30:54.642178 1 download.go:57] Using image internal scripts from: image:///usr/local/sti/save-artifacts I0805 02:30:54.642201 1 sti.go:186] Using assemble from image:///usr/local/sti I0805 02:30:54.642216 1 sti.go:186] Using run from image:///usr/local/sti I0805 02:30:54.642223 1 sti.go:186] Using save-artifacts from image:///usr/local/sti I0805 02:30:54.642234 1 sti.go:121] Clean build will be performed I0805 02:30:54.642240 1 sti.go:124] Performing source build from https://github.com/chmouel/simple-dockerfile.git I0805 02:30:54.642246 1 sti.go:134] Building 172.30.164.136:5000/jialiu/simple-dockerfile:latest <--snip-->
I doubt it's the cause, but can you verify that the date is set properly on all hosts?
Are you using a proxy in your build config?
No proxy straight to the internet on AWS, as for the date they are all properly syncronize : [root@master ~]# date;for i in node1 node2;do ssh $i date;done Wed Aug 5 12:06:56 EDT 2015 Wed Aug 5 12:06:56 EDT 2015 Wed Aug 5 12:06:57 EDT 2015
what do you see if you run the following on the nodes: curl -s -vvv https://github.com > /dev/null and this within a container on the nodes: docker run openshift/ruby-22-centos7 curl -s -vvv https://github.com > /dev/null
then try with this image: docker run registry.access.redhat.com/openshift3/python-33-rhel7:latest curl -s -vvv https://github.com > /dev/null
Still looking, but as far as I can tell there's no management of node /etc/resolv.conf in ansible. I suspect this is simply a misconfigured environment, you cannot have a search path that matches your wildcard dns.
NetworkManager / dhcp is adding the host's domain name to the search path. If your host's domain name matches the wildcard path then you'll end up with these problems. wildcard *.apps.example.com and {master,nodeX}.example.com is safe wildcard *.example.com and {master,nodeX}.example.com is not The problem exhibits itself in 3.0.1 because kubernetes changed the ndots value to 5 in order to allow for dns lookups on SRV lookup names like _dns._udp.kube-dns.default.svc to be considered relative and follow the search path. For more info on that change please see https://github.com/GoogleCloudPlatform/kubernetes/issues/10161 and https://github.com/GoogleCloudPlatform/kubernetes/pull/10266