Description of problem: - Jenkins image has hardcoded registry.access.redhat.com in S2I script. - Some users use mirror registry rather than registry.access.redhat.com, and they cannot use them with RHEL image. Version-Release number of selected component (if applicable): - OCP 3.3 How reproducible: - Please see: https://github.com/openshift/jenkins/blob/master/2/contrib/jenkins/kube-slave-common.sh#L27-L33 ~~~ NODEJS_SLAVE=registry.access.redhat.com/openshift3/jenkins-slave-nodejs-rhel7 MAVEN_SLAVE=registry.access.redhat.com/openshift3/jenkins-slave-maven-rhel7 # if the master is running the centos image, use the centos slave images. if [[ `grep CentOS /etc/redhat-release` ]]; then NODEJS_SLAVE=openshift/jenkins-slave-nodejs-centos7 MAVEN_SLAVE=openshift/jenkins-slave-maven-centos7 fi ~~~ Expected results: NODEJS_SLAVE, MAVEN_SLAVE or any variable which hardecoded with registry.access.redhat.com should be modifiable with environmental variables.
these are just default/sample configurations, users are welcome to delete these 2 slave image configurations and create their own pointing to any registry/image they desire. Marking low severity but not even sure it's worth doing anything here.
> these are just default/sample configurations, users are welcome to delete these 2 slave image configurations and create their own pointing to any registry/image they desire. Do you expect that users delete them and add new ones by build Jenkins image? If so, we don't think it is good idea, since they need to rebuild Jenkins image every time when RH releases updated Jenkins image in the future.
No, I would expect them to store their jenkins configuration on a persistent volume, just like any other aspect of their jenkins configuration (eg job definitions), so it would be retained when deploying new versions of the image.
Yes, existing image could work. But they still need to rebuild the image for brand new Jenkins deploy. (Even though users may not re-deploy Jenkins so often.)
you don't need to build an image to do a deployment. please explain your scenario in detail, from end to end.
Ah, I think I understand. I was thinking that 3-b will try to use the image from redhat.com, but it still use image from their own registry? 0. Modify kube-slave-common.sh 1. Build Jenkins base image: # cat Dockerfile From registry.access.redhat.com/openshift3/jenkins-1-rhel7 COPY kube-slave-common.sh /usr/local/bin/kube-slave-common.sh 2. Deploy the Jenkins image (w/ persistent volume) 3. RH released new base Jenkins image Then, -> a) For the image which has been deployed #2 above, it keeps using 2 slave image from their own registry. -> b) (I was thinking) For new updated Jenkins image which will be deployed after 3, it will try to use image from registry.access.redhat.com.
yeah, if they have created a deploymentconfig that deploys their own customized image, then the image on registry.access.redhat.com is irrelevant. of course if they want to pick up any fixes in the new registry.access.redhat.com image, they would want to rebuild their image(since it is built on top), but even then, any deployment triggered by that rebuild would still reuse the persistent volume (assuming they deployment was using one), not to mention that the image itself would have their changes in it.
So, after RH provides any fix in the new registry.access.redhat.com image, if users want to pick up them, they need to rebuild their images. I would appreciate it if you could update to handle it on jenkins' base image side, since these irregular update process make complicated users' workflow.
image will now support NODEJS_SLAVE_IMAGE and MAVEN_SLAVE_IMAGE env variables, you can point them to whatever valid docker image you want, including the registry path. if unspecified, the behavior will remain as it was. https://github.com/openshift/jenkins/pull/211
This should be fixed in openshift3/jenkins-slave-base-rhel7:1.0-13
Test with brew...openshift3/jenkins-2-rhel7 a4a84ae5500d openshift v3.5.0.16+a26133a kubernetes v1.5.2+43a9be4 etcd 3.1.0 $oc env dc/jenkins -e NODEJS_SLAVE_IMAGE=openshift3/jenkins-slave-nodejs-rhel7 -e MAVEN_SLAVE_IMAGE=openshift3/jenkins-slave-maven-rhel7 then login to jenkins webconsole, check jenkins slave image
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:0884