maven slave v3.6 centos image has incorrect version of oc

[spicysomtam]

This caught me out when I lost context on a maven slave; thought I was logged into a project but oc reported I was on the prior project. Thus I updated the v3.6 slave image with the correct oc version and it fixes the issue for me. Testing:

$ docker run -it openshift/jenkins-slave-maven-centos7:v3.6 bash
Using 64 bit Java since OPENSHIFT_JENKINS_JVM_ARCH is not set
bash-4.2$ oc version
oc v1.5.0+031cbe4
kubernetes v1.5.2+43a9be4
features: Basic-Auth GSSAPI Kerberos SPNEGO
bash-4.2$ ^C
bash-4.2$ exit

$ docker run -it openshift/jenkins-slave-maven-centos7:v3.6u1 bash
Using 64 bit Java since OPENSHIFT_JENKINS_JVM_ARCH is not set
bash-4.2$ oc version
oc v3.6.0+c4dd4cf
kubernetes v1.6.1+5115d708d7
features: Basic-Auth GSSAPI Kerberos SPNEGO
bash-4.2$ 

I did a pull on the image to see if it had been updated.

[bparees]

yeah, in the 3.6 timeframe we were manually managing the oc binary included in the images. starting with 3.7 the images are built on top of the origin base image so they always include a matched oc binary.

Since the v3.5 oc binary is compatible w/ openshift v3.6, we aren't going to go back and publish a new v3.6 image to fix this (we generally don't backport fixes to origin releases).

This caught me out when I lost context on a maven slave; thought I was logged into a project but oc reported I was on the prior project. Thus I updated the v3.6 slave image with the correct oc version and it fixes the issue for me

What issue did you actually have? If there is a legitimate problem w/ the v3.5 binary talking to your v3.6 cluster we might consider updating the image, but i haven't heard of any to date (and again for origin we'd more likely just encourage you to update to v3.7)

[bparees]

/cc @gabemontero

[spicysomtam]

Openshift is quite closely tied to a k8s release so it does not surprise me oc 1.5 (k8s 1.5) client has some issues against oc 3.6 (k8s 1.6) server.

Some logging for you. If I update to oc 3.6.0, the login context is correct. So I was logged into myapp-build, then I switch to project myapp-dev to sync the image streams up, but it still thinks I am on myapp-build. So basically build builds some new images and then switches to dev to refresh the images:

[testing2 git] Running shell script
+ oc login https://openshift.dc.myorg.co:8443 --insecure-skip-tls-verify=true --token=****
Logged into "https://openshift.dc.myorg.co:8443" as "system:serviceaccount:myapp-dev:****" using the token provided.

You have one project on this server: "myapp-dev"

Using project "myapp-dev".
[Pipeline] sh
[testing2 git] Running shell script
+ oc project myapp-dev
Already on project "myapp-dev" on server "https://openshift.dc.myorg.co:8443".
[Pipeline] }
[Pipeline] // withCredentials
[Pipeline] sh
[testing2 git] Running shell script
+ oc whoami -c
myapp-dev/openshift-clt1-lab-myorg-co:8443/system:serviceaccount:myapp-dev:jenkins
[Pipeline] sh
[testing2 git] Running shell script
+ oc config current-context
[Pipeline] echo
Context: myapp-dev/openshift-clt1-lab-myorg-co:8443/system:serviceaccount:myapp-dev:jenkins
[Pipeline] echo
Imagestreams and imagestream tags before re-import:
[Pipeline] sh
+ oc get is,istag
Error from server (Forbidden): User "system:serviceaccount:myapp-dev:jenkins" cannot list imagestreams in project "myapp-build"
Error from server (Forbidden): User "system:serviceaccount:myapp-dev:jenkins" cannot list imagestreamtags in project "myapp-build"

[bparees]

that's pretty weird and not sure how that would be caused by a v1.5 client talking to a 3.6 cluster, short of a straight up bug in 1.5.

anyway if you can move up to 3.7 i'd recommend that. if it's really blocking you we can consider updating the v3.6 image but i'd rather avoid that.

[bparees]

(also would be interested to see your full Jenkinsfile)

[spicysomtam]

Its no blocker; I created a Dockerfile to add the 3.6.0 client to the v3.6 image and tagged it as v3.6u1. We use our own internal docker registry hosted on jfrog artifactory and pull images from there. No big drama. But with the testing I have done, you need to stick to the oc client version for the version of openshift you are running, otherwise you will get some strange behaviour/incompatibilities.

Jenkinsfile is has quite a few steps. code checkout, deploy zookeeper, kafka and local dynamodb, then a build config to perform multiple scala builds (and tests; hence the zookeeper/kafka/dynamodb to test against). That runs for master and PR's using the github organisation jenkins plugin. If its a master build, further build configs pull built artifacts out of the builder image and generate docker images. There is a custom build to generate an nginx gateway, then a oc login to a dev environment to reimport imagestreams so the freshly built images are deployed to dev via imagestream triggers. The first big builder could do with a volume; docker is horribly slow extending its filesystem and an external volume would make it much quicker (confirmed this using s2i and docker natively; a docker volume makes the build much faster). Could share the Jenkinsfile.

[bparees]

yeah i was interested to see the jenkinsfile just in case there was something obvious in there tripping up oc.

Anyway we agree about trying to align your oc client w/ your cluster, though there is supposed to be guaranteed N-1 compatibility (as long as you aren't trying to use new apis w/ an old client of course)

Since you have a workaround i'm going to close this. Hopefully this problem becomes a non-issue as people move up to v3.7+

[spicysomtam]

We are going live soon with an app and have multiple cluster across different data centers. Thus there is very little chance we will upgrade any time soon. So 3.6.0 it is.