Created attachment 1209313 [details] Disable autobuild Description of problem: I am using the following for build pipelines https://paste.fedoraproject.org/448758/ This spawns a new jenkins stack in my project as expected. The issue comes when I create a new app. I use the "add to project" button and disable automatic build and deploy triggers (see screenshots) This gives an error when I fire off a pipeline build in the "deploy" step. It give an "image pull backoff" error because it cannot find `image:tag` image (see screenshot). It only works when I edit the deploymentConfig of the application and change the image to.. 172.30.198.59:5000/welcome-pipeline/welcome-php:latest Note; I tried doing `namespace/image:tag` but it doesn't work. You have to specify `router-svc-ip:5000/namespace/image:tag` [root@ose3-master ~]# oc version oc v3.3.0.34 kubernetes v1.3.0+52492b4 features: Basic-Auth GSSAPI Kerberos SPNEGO Server https://ose3-master.example.com:8443 openshift v3.3.0.34 kubernetes v1.3.0+52492b4 How reproducible: Always Steps to Reproduce: 1. Create a new project 2. In the WebUI - import pipeline builder yaml https://paste.fedoraproject.org/448758/ 3. Add app to project naming it to what the pipeline builder would be looking for (in the above example it's `welcome-php`) 4. Click "start-pipeline" Actual results: Build Succeeds Deployment Fails (ImagePull Backoff) Expected results: Build Succeeds Deployment Succeeds Additional info: Working DeploymentConfig (after I modify it): http://paste.fedoraproject.org/448760/15157147/ DeploymentConfig that isn't working (the one setup by OCP by default): https://paste.fedoraproject.org/448762/76215201/
Created attachment 1209314 [details] Disable Autodeploy
Created attachment 1209315 [details] Wrong Deployment config is configured
I tested using this simple php script https://github.com/christianh814/welcome-php
This is an expected behavior since you don't have the ICT defined. In this case you have to do "manual" deployment, so you have to set the image manually (you can use the "oc set image" for this (or call that command from Jenkins). Another option is to define the image change trigger and set "automatic=false". In this case when the deployment config is instantiated, it will resolve the image define inside image change trigger.
@zhou ying - ok thanks ... 1 more follow up, when you bring up the jenkins image, can you go to Manage Jenkins -> Manage Plugins page, then go to the installed tab, and confirm the plugin version. Otherwise, Michal - we'll need some help. What was the expected behavior when the plugin started using the instantiate endpoint? And if what Zhou Ying sees does not match that expected behavior, how should we go about diagnosing? thanks
@zhou ying - I just remembered that I saw in a github issue somewhere that the instantiate endpoint for deployment may only be available in 1.4. @Michal - is that correct?
(In reply to Gabe Montero from comment #15) > @zhou ying - I just remembered that I saw in a github issue somewhere that > the instantiate endpoint for deployment may only be available in 1.4. > > @Michal - is that correct? That is correct. The plugin should fallback to legacy code if the instantiate endpoint return 404 (which means the plugin is talking to older version). You might review the code Michalis did in "oc rollout latest".
Thanks for the confirm Michal. And yes, the plugin falls back if talking to the older version So Zhou Ying, if you are willing to test against the latest jenkins-1-centos7 image, you cannot run against 3.3.1.3. You need to run against a pre-release 3.4 install.
Moving to on qa for a retry against 1.4 / 3.4 and the latest jenkins image.
Thanks. Today, I can reproduce the issue with the latest OCP : openshift v3.4.0.18+ada983f kubernetes v1.4.0+776c994 etcd 3.1.0-rc.0 If only with 'ConfigChange' in triggers, use "oc rollout latest" still met error: failed to "StartContainer" for "nodejs-mongodb-example" with ImagePullBackOff: "Back-off pulling image. I must edit the dc with 172.30.187.114:5000/zhouy2/nodejs-mongodb-example:latest.
OK, QE is having issues with `oc rollout`, where jenkins and the pipeline plugin is not even being used. Sending over the Michal to have his team sort out the logisitcs with that. Once we are in sync with `oc rollout`, we can then revisit translating the scenario to Jenkins and use of the deploy instantiate endpoint.
@zhou in order to resolve the image in the DC you have to use an ICT, otherwise `oc rollout latest` will not resolve the image automagically for you. Automatic can be set to false if you want manual deployments, the ICT has to exist though. Not sure what can be done on our end apart from docs.
I have also opened https://github.com/openshift/origin-web-console/issues/808 in the web console repo to have the UI not remove the ICT when a user doesn't want automatic deployments on image updates but just set automatic to false.
(In reply to Michail Kargakis from comment #22) > I have also opened > https://github.com/openshift/origin-web-console/issues/808 in the web > console repo to have the UI not remove the ICT when a user doesn't want > automatic deployments on image updates but just set automatic to false. Web console change: https://github.com/openshift/origin-web-console/pull/810
The web console change was merged and the QA was guided how to use this, moving this ON_QA.
Has confirmed with latest OCP,the issue has fixed: openshift version openshift v3.4.0.24+52fd77b kubernetes v1.4.0+776c994 etcd 3.1.0-rc.0 When create app without 'New image is available ' on web console, check the DC, not remove the ICT and set the automatic to false. After 'start-pipeline' , when the build completed, could auto deploy with the latest images succeed.
*** Bug 1396970 has been marked as a duplicate of this bug. ***
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:0066