Description of problem: From [1]: $ oc adm release extract --to manifests quay.io/openshift-release-dev/ocp-release:4.6.0-fc.6-x86_64 Extracted release payload from digest sha256:933f3d6f61ddec9f3b88a0932b47c438d7dfc15ff1873ab176284b66c9cff76e created at 2020-09-14T21:50:05Z $ diff -u0 <(yaml2json <manifests/0000_50_cluster-storage-operator_01_operator_namespace.yaml | jq -S .) <(yaml2json <manifests/0000_50_cluster-csi-snapshot-controller-operator_00_namespace.yaml | jq -S .) --- /dev/fd/63 2020-09-15 21:57:52.836562697 -0700 +++ /dev/fd/62 2020-09-15 21:57:52.837562709 -0700 @@ -7,0 +8,3 @@ + "labels": { + "openshift.io/cluster-monitoring": "true" + }, Ideally, we'd either have a single manifest or [2,3] would match. Seems like the divergent overlap is from [4], which went out with 4.5.1 [5] and was backported to 4.4 [6]. Diverging by label isn't terrible, because the CVO merges labels [7,8] and only attempts to stomp the in-cluster object if the in-cluster object diverges in a manifest-specified key [9]. But would be nice to remove the risk of more serious divergence. Based on the manifest runlevel docs [10,11,12] (we need to cleanup and unify that a bit on the CVO side), you could have a single manifest that was installed before either operator on update if you moved it to runlevel 49 as 0000_49_cluster-storage-operator_01_operator_namespace.yaml or some such. Or you could leave the overlapping manifests, update one to remove any divergence, and punt unification into a single manifest to some future work if/when you ever need to make a change to the manifest that would temp the CVO into stomping back and forth on itself. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1879184#c2 [2]: https://github.com/openshift/cluster-storage-operator/blob/dd5f84fa86e68133d3295239ff426dd59f24039d/manifests/01_operator_namespace.yaml [3]: https://github.com/openshift/cluster-csi-snapshot-controller-operator/blob/65d4ecf55c44572e5c57ea685869506bce0bd4fe/manifests/00_namespace.yaml [4]: https://github.com/openshift/cluster-csi-snapshot-controller-operator/pull/34 [5]: https://bugzilla.redhat.com/show_bug.cgi?id=1815552#c11 [6]: https://bugzilla.redhat.com/show_bug.cgi?id=1816826 [7]: https://github.com/openshift/cluster-version-operator/blob/6d56c655ea16f6faee4b65ffef43dcd912657bc6/lib/resourceapply/core.go#L32 [8]: https://github.com/openshift/cluster-version-operator/blob/6d56c655ea16f6faee4b65ffef43dcd912657bc6/lib/resourcemerge/meta.go#L13 [9]: https://github.com/openshift/cluster-version-operator/blob/6d56c655ea16f6faee4b65ffef43dcd912657bc6/lib/resourcemerge/meta.go#L37 [10]: https://github.com/openshift/cluster-version-operator/blob/6d56c655ea16f6faee4b65ffef43dcd912657bc6/docs/dev/operators.md#what-is-the-order-that-resources-get-createdupdated-in [11]: https://github.com/openshift/cluster-version-operator/blob/6d56c655ea16f6faee4b65ffef43dcd912657bc6/docs/user/reconciliation.md#manifest-graph [12]: https://github.com/openshift/cluster-version-operator/blob/6d56c655ea16f6faee4b65ffef43dcd912657bc6/docs/dev/upgrades.md#generalized-ordering
Waiting for 4.7 to open: https://github.com/openshift/cluster-storage-operator/pull/89 https://github.com/openshift/cluster-csi-snapshot-controller-operator/pull/49
Waiting for 4.7 to open:
Both PRs are merged
Verified with: 4.7.0-0.nightly-2020-10-17-034503
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 (Moderate: OpenShift Container Platform 4.7.0 security, bug fix, and enhancement update), 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/RHSA-2020:5633