Description of problem: There is change in number of role bindings which EAP operator creates. Our tests started to fail as new role binding has shown up in the namespace. Before on OCP 4.6 there was only roleBinding: eap-operator.v2.0.2-eap-operator-6f6b6d64c5 however on OCP 4.7 there additional roleBinding: eap-operator.v2.0.2. The version of EAP operator is the same and only change is OCP 4.6 -> 4.7. Currently this is failing our test automation as clean up procedure does not expect to delete this resource. Is this change expected? Version-Release number of selected component (if applicable): 4.7.0-0.nightly-2021-01-19-033533 Actual results: Expected results: Additional info: eap-operator.v2.0.2-eap-operator-6f6b6d64c5 kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: selfLink: >- /apis/rbac.authorization.k8s.io/v1/namespaces/mnovak-cd3/rolebindings/eap-operator.v2.0.2-eap-operator-6f6b6d64c5 resourceVersion: '737643' name: eap-operator.v2.0.2-eap-operator-6f6b6d64c5 uid: 9f999e72-3444-4fde-93be-c43de3f4c36f creationTimestamp: '2021-01-20T14:17:30Z' managedFields: - manager: catalog operation: Update apiVersion: rbac.authorization.k8s.io/v1 time: '2021-01-20T14:17:30Z' fieldsType: FieldsV1 fieldsV1: 'f:metadata': 'f:labels': .: {} 'f:olm.owner': {} 'f:olm.owner.kind': {} 'f:olm.owner.namespace': {} 'f:ownerReferences': .: {} 'k:{"uid":"b5cae370-021e-4c60-9603-ac7c64c0505c"}': .: {} 'f:apiVersion': {} 'f:blockOwnerDeletion': {} 'f:controller': {} 'f:kind': {} 'f:name': {} 'f:uid': {} 'f:roleRef': 'f:apiGroup': {} 'f:kind': {} 'f:name': {} 'f:subjects': {} - manager: olm operation: Update apiVersion: rbac.authorization.k8s.io/v1 time: '2021-01-20T14:17:35Z' fieldsType: FieldsV1 fieldsV1: 'f:metadata': 'f:labels': 'f:operators.coreos.com/eap.mnovak-cd3': {} namespace: mnovak-cd3 ownerReferences: - apiVersion: operators.coreos.com/v1alpha1 kind: ClusterServiceVersion name: eap-operator.v2.0.2 uid: b5cae370-021e-4c60-9603-ac7c64c0505c controller: false blockOwnerDeletion: false labels: olm.owner: eap-operator.v2.0.2 olm.owner.kind: ClusterServiceVersion olm.owner.namespace: mnovak-cd3 operators.coreos.com/eap.mnovak-cd3: '' subjects: - kind: ServiceAccount name: eap-operator namespace: mnovak-cd3 roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: eap-operator.v2.0.2-eap-operator-6f6b6d64c5 eap-operator.v2.0.2: kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: eap-operator.v2.0.2 namespace: mnovak-cd3 selfLink: >- /apis/rbac.authorization.k8s.io/v1/namespaces/mnovak-cd3/rolebindings/eap-operator.v2.0.2 uid: 4ec11fd1-eca2-4f12-a489-4f2f5c3465a0 resourceVersion: '738476' creationTimestamp: '2021-01-20T14:19:55Z' ownerReferences: - apiVersion: operators.coreos.com/v1 kind: OperatorCondition name: eap-operator.v2.0.2 uid: 8bf0dffc-a42b-411a-892c-611c30a6c42b controller: true blockOwnerDeletion: false managedFields: - manager: olm operation: Update apiVersion: rbac.authorization.k8s.io/v1 time: '2021-01-20T14:19:55Z' fieldsType: FieldsV1 fieldsV1: 'f:metadata': 'f:ownerReferences': .: {} 'k:{"uid":"8bf0dffc-a42b-411a-892c-611c30a6c42b"}': .: {} 'f:apiVersion': {} 'f:blockOwnerDeletion': {} 'f:controller': {} 'f:kind': {} 'f:name': {} 'f:uid': {} 'f:roleRef': 'f:apiGroup': {} 'f:kind': {} 'f:name': {} 'f:subjects': {} subjects: - kind: ServiceAccount name: eap-operator roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: eap-operator.v2.0.2
Any update on this one? We need to know whether this is issue so we can decide whether we must fix it in the test suite or not. Thanks, Mirek
This doesn't appear to be a bug at all. That rolebinding is explicitly related to the operatorcondition CRD that was introduced in 4.7 and is separate from the other rolebinding because OLM is making an explicit relationship between any installed operator and the role so that operators can write to that condition CRD by default. I'm closing this as NOTABUG. If you have any further questions about this topic, feel free to reach out on the CoreOS slack channel #forum-operator-fw or on our email list aos-odin
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days