Bug 2084215 - Resource configmap "openshift-machine-api/kube-rbac-proxy" is defined by 2 manifests
Summary: Resource configmap "openshift-machine-api/kube-rbac-proxy" is defined by 2 ma...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Bare Metal Hardware Provisioning
Version: 4.10
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 4.11.0
Assignee: Honza Pokorny
QA Contact: Jad Haj Yahya
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-05-11 16:44 UTC by Jack Ottofaro
Modified: 2022-08-10 11:11 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-08-10 11:11:18 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift cluster-baremetal-operator pull 272 0 None open Bug 2084215: Add baremetal prefix to kube-rbac-proxy 2022-06-21 14:14:57 UTC
Red Hat Product Errata RHSA-2022:5069 0 None None None 2022-08-10 11:11:45 UTC

Description Jack Ottofaro 2022-05-11 16:44:35 UTC
Description of problem:

Resource defined by 0000_31_cluster-baremetal-operator_05_kube-rbac-proxy-config.yaml is also defined by openshift/machine-api-operator [1] openshift/0000_30_machine-api-operator_10_kube-rbac-proxy-config.yaml [2] but without the capability "baremetal" annotation. Results in the configmap being deployed on the cluster regardless of whether baremetal is enabled but the real issue is that the same resource is defined in two places and both end up in a release.

[1] https://github.com/openshift/cluster-baremetal-operator/blob/master/manifests/0000_31_cluster-baremetal-operator_05_kube-rbac-proxy-config.yaml
[2] https://github.com/openshift/machine-api-operator/blob/383c9b959b69044ec533118cf5d41f17101137f1/install/0000_30_machine-api-operator_10_kube-rbac-proxy-config.yaml

Comment 1 W. Trevor King 2022-05-11 17:54:47 UTC
Setting blocker+ for 4.11, because with the current name overlap, clusters that do not include 'baremetal' in ClusterVersion spec.capabilities will have it implicitly included after their first update:

1. User installs a cluster without 'baremetal'.
2. User asks to update.
3. Cluster-version operator reviews manifests comparing group/kind/namespace/name, sees that it is currently reconciling the ConfigMap, sees that the incoming release has the ConfigMap with a 'baremetal' annotation, and implicitly enables the 'baremetal' capability.
4. Cluster-version operator begins reconciling the other 'baremetal' manifests to install/reconcile the capability.

Looks like the overlapping manifest name dates back to at least 4.8 [1,2], but the capability angle is only important for 4.11 and later.

[1]: https://github.com/openshift/cluster-baremetal-operator/blob/release-4.8/manifests/0000_31_cluster-baremetal-operator_05_kube-rbac-proxy-config.yaml
[2]: https://github.com/openshift/cluster-baremetal-operator/commit/5d9301dc21f350a8c49a8a5117226c10dc0ed918

Comment 5 Jad Haj Yahya 2022-07-12 10:15:18 UTC
Verified on 4.11.0-0.nightly-2022-07-11-080250

Comment 6 errata-xmlrpc 2022-08-10 11:11:18 UTC
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 (Important: OpenShift Container Platform 4.11.0 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-2022:5069


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