Description of problem:
When there are one or more operators installed in a namespace with an OperatorGroup that targets all namespaces and where the operators provide a combined total of at least 2 APIs, OLMv0 sends ClusterRole updates to the APIserver with aggregation rule changes where the only change is the order of the aggregation rule selectors. This happens whenever the OperatorGroup is reconciled, which happens when other namespaces are created or deleted, among other triggers. This causes unnecessary churn with etcd writes and invalidation of auth caches in openshift-apiserver, which leads to yet more churn.
Version-Release number of selected component (if applicable):
4.19.0-rc.5
How reproducible:
Always
Steps to Reproduce:
1. Get a clusterbot 4.19.0-rc5 cluster 2. Install several operators in the global-operators namespace 3. Start a watch for the clusterrole with the name prefix "olm.og.global-operators.admin-" (e.g. oc get clusterrole olm.og.global-operators.admin-3gjDVezhGPF6RBtOOpjEpDpKqO39v3NK8r4hmc -w -o yaml) 4. Create and delete namespaces multiple times 5. Observe from the watch that there are changes to the clusterrole and that the only change is to the order of the selectors in the aggregation rule.
Actual results:
Writes to the clusterrole occur due to changing order of selectors.
Expected results:
Writes to the clusterrole do not occur, because the order of selectors is deterministic.
Additional info:
- is cloned by
-
OCPBUGS-57279 Unnecessary churn with OLMv0 operatorgroup clusterrole management
-
- Closed
-
- is depended on by
-
OCPBUGS-57279 Unnecessary churn with OLMv0 operatorgroup clusterrole management
-
- Closed
-
- links to