Investigating 4.8.0-fc.2: $ oc adm release extract --to manifests quay.io/openshift-release-dev/ocp-release:4.8.0-fc.2-x86_64 $ for X in manifests/*.yaml; do ENTRIES="$(yaml2json < "${X}" | jq -r '.[].metadata | select((.annotations // {}) | keys | tostring | contains("include.release.openshift.io/") | not) | .namespace + " " + .name + " " + (.annotations | tostring)')"; if test - n "${ENTRIES}"; then echo "${X}"; echo "${ENTRIES}"; fi done manifests/0000_20_kube-apiserver-operator_08_flowschema.yaml probes null ... That entry is [1], from [2]. Without the profile annotations, the CVO will never push it into the cluster. No sense in keeping the manifest around then. This bug can be used to land [3]. [1]: https://github.com/openshift/cluster-kube-apiserver-operator/blob/c03c9edf5fddf4e3fb1bc6d7afcd2a2284ca03d8/manifests/0000_20_kube-apiserver-operator_08_flowschema.yaml#L81-L82 [2]: https://github.com/openshift/cluster-kube-apiserver-operator/pull/1060 [3]: https://github.com/openshift/cluster-kube-apiserver-operator/pull/1099
We also have a dependency on https://bugzilla.redhat.com/show_bug.cgi?id=1927397
$ oc adm release extract --to manifests registry.ci.openshift.org/ocp/release:4.8.0-0.nightly-2021-06-03-055145 $ cd manifests $ grep -A10 'name: probes' *kube-apiserver*.yaml 0000_20_kube-apiserver-operator_08_flowschema.yaml: name: probes 0000_20_kube-apiserver-operator_08_flowschema.yaml-spec: 0000_20_kube-apiserver-operator_08_flowschema.yaml- distinguisherMethod: 0000_20_kube-apiserver-operator_08_flowschema.yaml- type: ByUser 0000_20_kube-apiserver-operator_08_flowschema.yaml- matchingPrecedence: 2 0000_20_kube-apiserver-operator_08_flowschema.yaml- priorityLevelConfiguration: 0000_20_kube-apiserver-operator_08_flowschema.yaml- name: exempt 0000_20_kube-apiserver-operator_08_flowschema.yaml- rules: 0000_20_kube-apiserver-operator_08_flowschema.yaml- - nonResourceRules: 0000_20_kube-apiserver-operator_08_flowschema.yaml- - nonResourceURLs: 0000_20_kube-apiserver-operator_08_flowschema.yaml- - '/healthz' The probes flowschema was already in, and the dependent bug 1927397 was verified, see https://bugzilla.redhat.com/show_bug.cgi?id=1927397#c7, so move the bug VERIFIED.
The goal is to _not_ have the manifest anymore, since a manifest without cluster-profile annotations is useless. But looks like the PR actually made it into the next nightly [1]. Confirming by applying the check from comment 0 to the new nightly: $ oc adm release extract --to manifests registry.ci.openshift.org/ocp/release:4.8.0-0.nightly-2021-06-03-084005 Extracted release payload from digest sha256:3004ed7d5578c286481f40de3e420bf4773a1ffc6d75c8d7a9392db39655c5bd created at 2021-06-03T08:42:49Z $ for X in manifests/*.yaml; do ENTRIES="$(yaml2json < "${X}" | jq -r '.[].metadata | select((.annotations // {}) | keys | tostring | contains("include.release.openshift.io/") | not) | .namespace + " " + .name + " " + (.annotations | tostring)')"; if test -n "${ENTRIES}"; then echo "${X}"; echo "${ENTRIES}"; fi done manifests/0000_31_cluster-baremetal-operator_05_prometheus_rbac.yaml null manifests/0000_31_cluster-baremetal-operator_05_rbac.yaml null manifests/0000_90_cluster-baremetal-operator_03_servicemonitor.yaml openshift-machine-api cluster-baremetal-operator-servicemonitor {"exclude.release.openshift.io/internal-openshift-hosted":"true"} Those baremetal entries are bug 1956607. So this bug is appropriately VERIFIED, but not for the reasons given in comment 3. [1]: https://amd64.ocp.releases.ci.openshift.org/releasestream/4.8.0-0.nightly/release/4.8.0-0.nightly-2021-06-03-084005
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.8.2 bug fix and security 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-2021:2438