OperatorHub instructions result in ClusterRoleBindings that are ineffective

[kingdonb]

Following the OperatorHub instructions literally results in the flux operator going in the operators namespace

https://operatorhub.io/operator/flux

The ClusterRoleBindings have hardcoded references to flux-system for the service accounts that should be used as the default SA for Flux reconcilers. The result is some ineffective ClusterRoleBindings that do not grant any permission to any extant service accounts.

I mentioned this in:

• flux logs not compatible with OLM flux operator fluxcd/flux2#1673

but wanted to open a separate issue to track it here, since it is definitely not a flux CLI problem.

[chanwit]

Thank you Kingdon!
Only an idea I have at the moment to solve this problem is to have another operator to install Flux for us.

wdyt?

[kingdonb]

[snip]

This discussion was meant for the logs issue, I'm mixed up sorry. (Moving these notes over to the Draft PR.)

I think we have enough operators already, we're going to need a "Yo dawg" meme in the documentation if there are any more. "I heard you like operators, so I put an operator in your operator lifecycle manager, then used it to install another operator..."

[kingdonb]

Maybe you already saw: operator-framework/kubectl-operator#50 (comment)

... in an ideal world an operator should be able to be installed in any namespace and have its RBAC correctly bound based on the installation namespace. That's currently a limitation of OLM, so not much we can do about it right now.