Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1375820 - ConfigChange in DeploymentConfig doesn't work if ImageChange has wrong ImageStreamTag name
ConfigChange in DeploymentConfig doesn't work if ImageChange has wrong ImageS...
Status: CLOSED ERRATA
Product: OpenShift Container Platform
Classification: Red Hat
Component: Deployments (Show other bugs)
3.2.1
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Michail Kargakis
zhou ying
:
: 1376192 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-09-14 00:52 EDT by Kenjiro Nakayama
Modified: 2017-03-08 13 EST (History)
6 users (show)

See Also:
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 05:47:34 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2650571 None None None 2016-09-23 01:43 EDT
Red Hat Product Errata RHBA-2016:1933 normal SHIPPED_LIVE Red Hat OpenShift Container Platform 3.3 Release Advisory 2016-09-27 09:24:36 EDT

  None (edit)
Description Kenjiro Nakayama 2016-09-14 00:52:45 EDT
Description of problem:
===

  ConfigChange in DeploymentConfig doesn't work if ImageChange has wrong ImageStreamTag

Version-Release number of selected component (if applicable):
===

  OSE 3.2

How reproducible:
===
Steps to Reproduce:
  1. Deploy application with triggers ConfigChange and ImageChange
    (e.g) # oc new-app jenkins

  2. Edit ImageStreamTag with wrong value

    (e.g) # oc edit dc jenkins

  before:

            kind: ImageStreamTag
          name: jenkins:1
          namespace: openshift

  after:
            kind: ImageStreamTag
          name: jenkins:111111
          namespace: openshift

*NOTE*: imageStreamTag "jenkins:111111" doesn't exist and invalid value.

  3. Edit any values under spec.template

Actual results:
===

  In #3, editing any value doesn't triger pod deploy

Expected results:
===

  "kinde.ImageStreamTag" should effect only for ImageChange(?)
  The documentation didn't expalin about it.
  https://docs.openshift.com/enterprise/3.2/dev_guide/deployments.html#config-change-trigger
Comment 1 Michail Kargakis 2016-09-14 06:18:35 EDT
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.
Comment 2 Kenjiro Nakayama 2016-09-14 06:39:04 EDT
(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
Comment 3 Michail Kargakis 2016-09-14 06:58:28 EDT
Tested on 3.3 w/o an issue. Is this only a 3.2.1 issue?
Comment 4 Kenjiro Nakayama 2016-09-14 07:03:10 EDT
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
Comment 5 Kenjiro Nakayama 2016-09-14 07:04:06 EDT
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).
Comment 6 Michail Kargakis 2016-09-14 07:13:38 EDT
I am not asking about 3.3 since I already tested it but for earlier versions (3.2, 3.1)
Comment 7 Michail Kargakis 2016-09-14 07:25:57 EDT
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.
Comment 9 Michail Kargakis 2016-09-15 06:04:06 EDT
*** Bug 1376192 has been marked as a duplicate of this bug. ***
Comment 12 zhou ying 2016-09-19 02:22:22 EDT
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
Comment 14 errata-xmlrpc 2016-09-27 05:47:34 EDT
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

Note You need to log in before you can comment on or make changes to this bug.