Bug 1375820
Summary: | ConfigChange in DeploymentConfig doesn't work if ImageChange has wrong ImageStreamTag name | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Kenjiro Nakayama <knakayam> |
Component: | openshift-controller-manager | Assignee: | Michail Kargakis <mkargaki> |
Status: | CLOSED ERRATA | QA Contact: | zhou ying <yinzhou> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 3.2.1 | CC: | aos-bugs, erich, knakayam, mfojtik, mkargaki, tdawson |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: |
In 3.3 once all images coming from image triggers are resolved inside the deployment config, we trigger on any config change as we should. If the trigger has a wrong ImageStreamTag name from the start then users are out of luck.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2016-09-27 09:47:34 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: |
Description
Kenjiro Nakayama
2016-09-14 04:52:45 UTC
This is not because the ImageStreamTag is wrong but because the DC has no clue that an image exists (ie. ICT.lastTriggeredImage is empty). Try to run a deployment with a valid ICT value, then change the ImageStreamTag to an invalid value and trigger a new deployment. It should run because now the DC has an image that it can run for this trigger. I am still not sure what to do in cases where users have messed up lastTriggeredImage or the encoding annotation of DC in the latest RC. They are sadly out of luck at the moment. (In reply to Michail Kargakis from comment #1) > This is not because the ImageStreamTag is wrong but because the DC has no > clue that an image exists (ie. ICT.lastTriggeredImage is empty). I'm sorry, but have you tested reproduce steps? I can reproduce the issue 100% on my environment. Also, could you please elaborate on the "lastTriggeredImage"? My DC has the value and it exists. lastTriggeredImage: registry.access.redhat.com/openshift3/jenkins-1-rhel7:latest Tested on 3.3 w/o an issue. Is this only a 3.2.1 issue? Yes, I am testing it with OSE 3.2.1. [joe@knakayam-ose32-master1 ~]$ openshift version openshift v3.2.1.1-1-g33fa4ea kubernetes v1.2.0-36-g4a3f9c5 etcd 2.2.5 [joe@knakayam-ose32-master1 ~]$ oc version oc v3.2.1.1-1-g33fa4ea kubernetes v1.2.0-36-g4a3f9c5 But I am not sure if it is only 3.2.1 issue or not, since 3.3 is not released yet (and we support and customer haven't used it). I am not asking about 3.3 since I already tested it but for earlier versions (3.2, 3.1) Nevermind, I've tested in both 1.2.0 and 1.1.6 (which has a different issue on top of this). So the bug was always there and is fixed for 1.3. *** Bug 1376192 has been marked as a duplicate of this bug. *** Confirmed with OCP3.3, the issue has fixed: openshift version openshift v3.3.0.31 kubernetes v1.3.0+52492b4 etcd 2.3.0+git Steps: 1) Create app: `oc new-app openshift/deployment-example` 2) Edit the DC ImageStreamTag with wrong value 3) Edit any values under spec.template: [root@zhouy dedicated]# oc set env dc/deployment-example key=values deploymentconfig "deployment-example" updated [root@zhouy dedicated]# oc get po NAME READY STATUS RESTARTS AGE deployment-example-1-g7gyq 1/1 Running 0 <invalid> deployment-example-2-3c6q9 0/1 ContainerCreating 0 <invalid> deployment-example-2-deploy 1/1 Running 0 <invalid> [root@zhouy dedicated]# oc get po NAME READY STATUS RESTARTS AGE deployment-example-2-3c6q9 1/1 Running 0 <invalid> [root@zhouy dedicated]# oc env po deployment-example-2-3c6q9 --list # pods deployment-example-2-3c6q9, container deployment-example key=values 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-2016:1933 |