Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1538731

Summary: image.openshift.io/triggers for initContainers fails to replace image field
Product: OpenShift Container Platform Reporter: Joseph Callen <jcallen>
Component: openshift-apiserverAssignee: Stefan Schimanski <sttts>
Status: CLOSED DEFERRED QA Contact: Wang Haoran <haowang>
Severity: low Docs Contact:
Priority: low    
Version: 3.7.0CC: aos-bugs, jcallen, jlieskov, jokerman, mfojtik, mmccomas, rromerom
Target Milestone: ---   
Target Release: 3.9.z   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-11-20 19:05:29 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 Flags
v37-with-initcontainer-spec-image-defined
none
v37-with-initcontainer-spec-image-undefined
none
v39-with-initcontainer-spec-image-undefined none

Description Joseph Callen 2018-01-25 17:04:51 UTC
Description of problem:

While using a template [0] that contains the image.openshift.io/trigger annotation to trigger on ImageStreamTag change the statefulset spec.template.spec.image field will be modified to the image url.  The initContainers spec.template.spec.image will not be updated and fails to start the init container with:

Pod "mariadb-galera-0" is invalid: spec.initContainers[0].image: Invalid value: " ": must not have leading or trailing whitespace

I tested the same template with version:

oc v3.9.0-alpha.3+8b81ebd-137
kubernetes v1.9.1+a0ce1bc657
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://127.0.0.1:8443
openshift v3.9.0-alpha.3+189d01b-196
kubernetes v1.9.1+a0ce1bc657

and it deployment succeeds.


[0] - https://github.com/jcpowermac/mariadb-ha-poc/blob/master/mariadb-galera-ephemeral-template.yml


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

oc v3.7.14                    
kubernetes v1.7.6+a08f5eeb62  
features: Basic-Auth GSSAPI Kerberos SPNEGO                  

Server https://ose-master1.virtomation.com:8443              
openshift v3.7.14             
kubernetes v1.7.6+a08f5eeb62  


How reproducible:
Consistently

Steps to Reproduce:
1. oc new-project galera ; oc create -f https://raw.githubusercontent.com/jcpowermac/mariadb-ha-poc/master/mariadb-galera-ephemeral-template.yml ; oc new-app --template mariadb-galera-ephemeral
2. oc get event --watch


Actual results:
init container fails to start and image field is empty 


Expected results:
init container starts and exits successfully with a properly defined image field.


Additional info:

If I replace initContainer image with the correct string the init container starts as expected. The statefulset container image field is always properly modified.

Comment 1 Michal Fojtik 2018-01-29 12:31:33 UTC
I tried to reproduce this but it seems like the `is/mariadb-galera:latest` is not imported properly. The tag does not exists and therefore the trigger will not replace the image field in initContainers.

I tried to manually force to import busybox:latest as mariadb-galera:latest and the trigger worked as expected:

$ oc tag --source docker busybox:latest mariadb-galera:latest # (This will just simulate that the tag is available)
$ oc get statefulset/mariadb-galera -o yaml | ack busybox
        image: busybox@sha256:4cee1979ba0bf7db9fc5d28fb7b798ca69ae95a47c5fecf46327720df4ff352d
        image: busybox@sha256:4cee1979ba0bf7db9fc5d28fb7b798ca69ae95a47c5fecf46327720df4ff352d

(this means the image was resolved properly).

Comment 2 Joseph Callen 2018-02-01 18:26:36 UTC
Michal,

The ImageStream `mariadb-galera` is a output location for the BuildConfig of the same name (templated). The only import is `docker.io/centos/mariadb-102-centos7:latest`.

SUCCESS: I replaced the initContainer image string [0] with the URL of the image location.  
After the BuildConfig completes the init container and container starts and runs correctly. [1]

Image trigger annotations for initContainers should work in v3.7 [2] right?

FAILURE: Testing with v3.7 with undefined url in initContainer image. [3]

SUCCESS: Testing with 'openshift v3.9.0-alpha.4+3dcad95-52' using 'oc cluster up'.  Runs correctly not including the initContainer image URL.[4]

Attached `oc get events` for each testing.

[0] - https://github.com/jcpowermac/mariadb-ha-poc/blob/55ad8d2793c88e1ef1b194ffbf37dc5e8254243d/testing/init-defined.yml#L84
[1] - https://asciinema.org/a/160553
[2] - https://github.com/openshift/origin/blob/284b8b758829448a3a5fc9ba66506320becf1c94/pkg/image/trigger/annotations/annotations.go#L54
[3] - https://asciinema.org/a/160556
[4] - https://asciinema.org/a/160558

Comment 3 Joseph Callen 2018-02-01 18:27:34 UTC
Created attachment 1389672 [details]
v37-with-initcontainer-spec-image-defined

Comment 4 Joseph Callen 2018-02-01 18:27:56 UTC
Created attachment 1389674 [details]
v37-with-initcontainer-spec-image-undefined

Comment 5 Joseph Callen 2018-02-01 18:28:20 UTC
Created attachment 1389675 [details]
v39-with-initcontainer-spec-image-undefined

Comment 6 Ruben Romero Montes 2018-02-01 21:03:35 UTC
I could reproduce it as well with Elasticsearch Statefulset. Having only one trigger for the container it works and populates the image value:

    image.openshift.io/triggers: |
      [{
      "from": {
        "kind": "ImageStreamTag",
        "name": "elasticsearch:6.1.2"
        },
        "fieldPath": "spec.template.spec.containers[?(@.name==\"elasticsearch\")].image"
      }]
...
      containers:
      - name: elasticsearch
        image: ' '

After creating the StatefulSet:
        image: 172.30.1.1:5000/ek-apb-002/elasticsearch@sha256:70629ad1d3976baca1d98ef377e0b03a73cc90648b0423fd4edd950b7d552b6d

As Joseph mentioned before, when having also the trigger for the initcontainer it complains about the image value being ' '.

Comment 7 Stephen Cuppett 2019-11-20 19:05:29 UTC
OCP 3.6-3.10 is no longer on full support [1]. Marking CLOSED DEFERRED. If you have a customer case with a support exception or have reproduced on 3.11+, please reopen and include those details. When reopening, please set the Target Release to the appropriate version where needed.

[1]: https://access.redhat.com/support/policy/updates/openshift

Comment 8 Stephen Cuppett 2019-11-20 19:06:38 UTC
OCP 3.6-3.10 is no longer on full support [1]. Marking CLOSED DEFERRED. If you have a customer case with a support exception or have reproduced on 3.11+, please reopen and include those details. When reopening, please set the Target Release to the appropriate version where needed.

[1]: https://access.redhat.com/support/policy/updates/openshift