Cluster version is 4.4.0-0.nightly-2020-03-05-205718 mac:~ jianzhang$ oc exec catalog-operator-66cfd9d65c-qrq2v -n openshift-operator-lifecycle-manager -- olm --version OLM version: 0.14.2 git commit: 243899f2df0dc213056cbeb401c4b4844c1cd8b5 mac:~ jianzhang$ cat cs-env.yaml apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: etcd-env-operator namespace: openshift-marketplace spec: sourceType: grpc image: quay.io/jiazha/etcd-operator:env2 displayName: ETCD Env Operators publisher: jian mac:~ jianzhang$ oc get catalogsource NAME DISPLAY TYPE PUBLISHER AGE certified-operators Certified Operators grpc Red Hat 4h30m community-operators Community Operators grpc Red Hat 4h30m etcd-env-operator ETCD Env Operators grpc jian 28m mac:~ jianzhang$ oc create -f sub-env2.yaml subscription.operators.coreos.com/etcd-env-5m4d7 created mac:~ jianzhang$ cat sub-env2.yaml apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: generateName: etcd-env- namespace: default spec: source: etcd-env-operator sourceNamespace: openshift-marketplace name: etcd startingCSV: etcdoperator.v0.9.2 channel: alpha config: env: - name: ARGS1 value: "-v=4" - name: EMPTY_ENV mac:~ jianzhang$ oc get csv -n default NAME DISPLAY VERSION REPLACES PHASE elasticsearch-operator.4.4.0-202003021217 Elasticsearch Operator 4.4.0-202003021217 Succeeded etcdoperator.v0.9.2 etcd 0.9.2 Succeeded Still failed to config the operator env. As follows: mac:~ jianzhang$ oc -n default get deployment etcd-operator -o json|jq '.spec.template.spec.containers[0].env' [ { "name": "MY_POD_NAMESPACE", "valueFrom": { "fieldRef": { "apiVersion": "v1", "fieldPath": "metadata.namespace" } } }, { "name": "MY_POD_NAME", "valueFrom": { "fieldRef": { "apiVersion": "v1", "fieldPath": "metadata.name" } } } ]
Created attachment 1668035 [details] olm-operator.log
Created attachment 1668036 [details] catalog-operator.log
https://bugzilla.redhat.com/show_bug.cgi?id=1751443#c37 Please see this comment on the 4.5 bug. Can we verify that is not the issue? It is stymieing that this works for us every time we test. I would like to find a consistent way to reproduce, or determine that we've been miscommunicating about the feature (see the linked comment).
Cluster version is 4.4.0-0.nightly-2020-03-25-223508. [hui@localhost ocp-25644]$ oc exec catalog-operator-7cc7697bbd-6zsrq -n openshift-operator-lifecycle-manager -- olm --version OLM version: 0.14.2 git commit: 915c118f5845e72265ecd9b2cf59a1a26819fb92 The test procedure is same as comment 3. Actual results: [hui@localhost 1751443]$ oc get deployment etcd-operator -o yaml -n default|grep "\- command" -A 30 - command: - etcd-operator - --create-crd=false - $(ARGS1) - $(ARGS2) env: - name: MY_POD_NAMESPACE valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.namespace - name: MY_POD_NAME valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.name - name: ARGS1 value: -v=4 - name: EMPTY_ENV image: quay.io/coreos/etcd-operator@sha256:c0301e4686c3ed4206e370b42de5a3bd2229b9fb4906cf85f3f30650424abec2 The newly added env is added to deployment spec. Then check the env var $(ARGS1) in the command is replaced by its value -v=4. [hui@localhost 1751443]$ oc get pods NAME READY STATUS RESTARTS AGE etcd-operator-869c4bd946-6l2pl 3/3 Running 0 2m24s [hui@localhost 1751443]$ oc rsh etcd-operator-869c4bd946-6l2pl Defaulting container name to etcd-operator. Use 'oc describe pod/etcd-operator-869c4bd946-6l2pl -n default' to see all of the containers in this pod. / $ ps -elf |cat PID USER TIME COMMAND 1 etcd-ope 0:00 etcd-operator --create-crd=false -v=4 $(ARGS2) # The env var $(ARGS1) is replaced by its value -v=4. 14 etcd-ope 0:00 /bin/sh -c TERM="xterm-256color" /bin/sh 20 etcd-ope 0:00 /bin/sh 21 etcd-ope 0:00 /bin/sh -c TERM="xterm-256color" /bin/sh 28 etcd-ope 0:00 /bin/sh 29 etcd-ope 0:00 ps -elf 30 etcd-ope 0:00 cat The env var $(ARGS1) is replaced by its value -v=4 in the command. It is what we expected. Mark the bug verified.
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-2020:0581