COO-1268: monitoring: create unique cluster roles

[jan--f]

Otherwise two stack with the same name in two namespaces try to create the same cluster roles.

Another option is to create the cluster roles via the bundle so we always have only one cluster role. This would also help with cleanup. The downside is that we always create the cluster roles whether they get used or not.

[openshift-ci-robot]

@jan--f: This pull request references COO-1268 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the bug to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Otherwise two stack with the same name in two namespaces try to create the same cluster roles.

Another option is to create the cluster roles via the bundle so we always have only one cluster role. This would also help with cleanup. The downside is that we always create the cluster roles whether they get used or not.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jan--f

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• pkg/controllers/monitoring/OWNERS [jan--f]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[simonpasquier]

shouldn't we rather update the cluster role binding's name? IIUC both stacks should create the same cluster role which shouldn't cause an issue.

[jan--f]

shouldn't we rather update the cluster role binding's name? IIUC both stacks should create the same cluster role which shouldn't cause an issue.

I did consider that. But that would require bigger changes in the reconcile logic I think. Currently we reschedule a reconcile event on errors.IsAlreadyExists(err). We'd need to skip this error for ClusterRoles. But that might cause issues with reconciling our state of those resources?

[simonpasquier]

What about stackComponentCleanup()? should it be updated too?

And what will happen to existing installations? I suppose that the operator will leave the old cluster roles + bindings behind?

[openshift-ci]

@jan--f: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/observability-operator-e2e	8223967	link	true	/test observability-operator-e2e

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.