Bug 1383804
| Summary: | Deployment Config has wrong configuration when using Pipelines Tech Preview | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Christian Hernandez <chernand> | ||||||||
| Component: | openshift-controller-manager | Assignee: | Samuel Padgett <spadgett> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | zhou ying <yinzhou> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 3.3.0 | CC: | aos-bugs, bparees, dyan, gmontero, jcantril, mfojtik, nschuetz, spadgett, tdawson, vwalek | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | x86_64 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: |
When "Autodeploy when: New image is available" was unchecked in the web console "add to project" page, the web console would not create an image change trigger on the new deployment config. This meant that users had to manually set an image using `oc set image` before deployments. Otherwise all deployments would fail with image pull back-off errors.
The web console was updated to add an image change trigger with "automatic: false". This prevents deployments from happening automatically when the image stream tag is updated, but lets users run `oc rollout` commands -- or using the "Deploy" action in the web console -- without any additional configuration.
|
Story Points: | --- | ||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2017-01-18 12:42:23 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Christian Hernandez
2016-10-11 19:47:41 UTC
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 |