Description of problem: The ingress clusteroperator does not set a level gate which allows the CVO to incorrectly believe it has been upgraded even if it fails to. Version-Release number of selected component (if applicable): 4.1.4 Steps to Reproduce: 1. oc adm release extract --to=/tmp/folder quay.io/openshift-release-dev/ocp-release:4.1.4 2. edit 0000_50_cluster-ingress-operator_03-cluster-operator.yaml and notice it does not have the level gate present in, for example, 0000_50_cluster-monitoring-operator_05-clusteroperator.yaml status: versions: - name: operator version: "4.1.4" Actual results: Without this level gate, the CVO can pass by the operator during the upgrade even if the operator fails to upgrade. Additional info: Urgency at request of ccoleman. release info should include: status: versions: - name: operator version: "0.0.1-snapshot"
Here's abbreviated output from my cluster: $ oc get clusteroperator ingress -o yaml apiVersion: config.openshift.io/v1 kind: ClusterOperator metadata: name: ingress spec: {} status: versions: - name: operator version: 4.2.0-0.ci-2019-07-24-105737 - name: ingress-controller version: registry.svc.ci.openshift.org/ocp/4.2-2019-07-24-105737@sha256:fa21c0544c23edbcf94f69e829e40885745f1174278e26c220c706564355cc48 So it's not clear to me what the problem is. Is this request to add a dummy value to the status field of our clusteroperator manifest[1]? If so, can you help me understand what purpose that dummy value serves? Maybe I'm misunderstanding the requirement. [1] https://github.com/openshift/cluster-monitoring-operator/blob/master/manifests/0000_50_cluster_monitoring_operator_05-clusteroperator.yaml
(In reply to Dan Mace from comment #1) > Here's abbreviated output from my cluster: > > $ oc get clusteroperator ingress -o yaml > apiVersion: config.openshift.io/v1 > kind: ClusterOperator > metadata: > name: ingress > spec: {} > status: > versions: > - name: operator > version: 4.2.0-0.ci-2019-07-24-105737 > - name: ingress-controller > version: > registry.svc.ci.openshift.org/ocp/4.2-2019-07-24-105737@sha256: > fa21c0544c23edbcf94f69e829e40885745f1174278e26c220c706564355cc48 > > So it's not clear to me what the problem is. Is this request to add a dummy > value to the status field of our clusteroperator manifest[1]? If so, can you > help me understand what purpose that dummy value serves? Maybe I'm > misunderstanding the requirement. > > [1] > https://github.com/openshift/cluster-monitoring-operator/blob/master/ > manifests/0000_50_cluster_monitoring_operator_05-clusteroperator.yaml My new understanding is that CVO learns the operator's version keys by reading the keys declared in the clusteroperator manifest.
Verified with 4.2.0-0.nightly-2019-07-28-222114 the issue has been fixed. # oc adm release extract --to=/tmp/2114 "registry.svc.ci.openshift.org/ocp/release:4.2.0-0.nightly-2019-07-28-222114" # cat 0000_50_cluster-ingress-operator_03-cluster-operator.yaml # This resource is not created by CVO, it is only used as a communication # mechanism to tell the CVO which ClusterOperator resource to wait for. # IngressController creates and updates this resource. apiVersion: config.openshift.io/v1 kind: ClusterOperator metadata: name: ingress status: versions: - name: operator version: "4.2.0-0.nightly-2019-07-28-222114"
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-2019:2922