Bug 1538731 - image.openshift.io/triggers for initContainers fails to replace image field
Summary: image.openshift.io/triggers for initContainers fails to replace image field
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: openshift-apiserver
Version: 3.7.0
Hardware: x86_64
OS: Linux
low
low
Target Milestone: ---
: 3.9.z
Assignee: Stefan Schimanski
QA Contact: Wang Haoran
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-01-25 17:04 UTC by Joseph Callen
Modified: 2019-11-20 19:06 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-20 19:05:29 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
v37-with-initcontainer-spec-image-defined (16.47 KB, text/plain)
2018-02-01 18:27 UTC, Joseph Callen
no flags Details
v37-with-initcontainer-spec-image-undefined (8.49 KB, text/plain)
2018-02-01 18:27 UTC, Joseph Callen
no flags Details
v39-with-initcontainer-spec-image-undefined (16.67 KB, text/plain)
2018-02-01 18:28 UTC, Joseph Callen
no flags Details

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


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