OLM OwnNamespace support

[blezoray]

Hello,

Today, with OLM (Operator Lifecycle Manager) on OpenShift, we are able to deploy flux operator only in cluster scope (AllNamespaces installation mode).
In consequence, all users can see the operator in the OpenShift console even if they can't create any instance.

The solution to hide the operator in the console is to support the other modes, OwnNamespace, SingleNamespace, MultiNamespace.

Could you support these other modes ?

Rgds, Bruno.

[stefanprodan]

The operator can only be installed once per cluster, if we enable MultiNamespace and people install it more than once, the operators will fight over the same Flux installation. If we only enable OwnNamespace and SingleNamespace will it allow multiple installs?

[stefanprodan]

I've found the doc that explains what these are https://olm.operatorframework.io/docs/advanced-tasks/operator-scoping-with-operatorgroups/

• OwnNamespace: If supported, the operator can be configured to watch for events in the namespace it is deployed in.
• SingleNamespace: If supported, the operator can be configured to watch for events in a single namespace that the operator is not deployed in.
• MultiNamespace: If supported, the operator can be configured to watch for events in more than one namespace.
• AllNamespaces: If supported, the operator can be configured to watch for events in all namespaces.

For this list, the flux-operator is only compatible with OwnNamespace and AllNamespaces

[stefanprodan]

Flux Operator v0.6.0 published on OperatorHub adds support for the OwnNamespace install method. Please let me know if it works for you.

[blezoray]

After reflection, it seems preferable to me, that the operator should be deployed with AllNamespaces mode with the condition the ClusterServiceVersion integrates all the flux operator CRD (GitRepository, Kustomization, ...).

With this condition, all users can see in the OpenShift console its flux resources like when you deploy the "previous" flux operator.

[stefanprodan]

The previous one wasn’t an operator, it just deployed all Flux controllers with no option to configure them. The Flux CRDs and controllers are now managed by flux-operator, you need to apply a FluxInstance for them to be installed, so the UX is very different. Not sure how this impacts end-users who are not cluster admins.

[blezoray]

Agree. The specific usecase for Flux is that it has several controllers and a set of CRDs and the flux operator manages FluxInstance resource which deploys the cluster flux instance. But the UX in the OpenShift Console with OLM implies that when the CRDs are embedded in the CSV to be managed within the console.

This is the same case for External Secrets Operator, based on the helm operator SDK. there is the OperatorConfig that permits to specify the configuration of the controllers (controller + cert-manager controller + webhook) it deploys

External Secrets Operator CSV : https://github.com/redhat-openshift-ecosystem/community-operators-prod/blob/main/operators/external-secrets-operator/0.9.19/manifests/external-secrets-operator.clusterserviceversion.yaml#L693-L759