Question: Operator 0.3.4 no longer able to operate over all namespaces?

[bukovjanmic]

Hi,

we had the previous version of operator (0.2.4) installed via OLM, serving all namespaces.

The new version (0.3.4) failed to upgrade, so we deleted the old version and try to install the new one.

However, only installation to a selected namespace is offered, not to all namespaces as before.

Is this intentional so now we have to run the operator in each namespace we want to use it or is it a bug?

We are running on OCP 4.6.42.

Thanks,

Michal Bukovjan

[bukovjanmic]

/kind feature

[slopezz]

Hi @bukovjanmic, let me explain the reason of the different installModes.

Despite the fact operator-sdk supposes by default that an operator will have always cluster-role/cluster-role-binding for rbac permission on a cluster scope operator, we replaced that rbac by role/role-binding because we wanted to have a namespace scope operator because on certain scenarioscluster-scope-operator might not be allowed.

So, onv0.2.X, we permitted in the CSV the installMode AllNamespaces=true because was a default value for operator-sdk project scaffolding, not because we wanted it, these were the values from the CSV:

  installModes:
  - supported: true
    type: OwnNamespace
  - supported: true
    type: SingleNamespace
  - supported: false
    type: MultiNamespace
  - supported: true
    type: AllNamespaces

Then, on v0.3.X, which represented a major upgrade because we switched from operator-sdk:v0.X to operator-sdk:v1.X introducing many breaking changes (documented at https://github.com/3scale-ops/prometheus-exporter-operator/releases/tag/v0.3.0), we:

• Updated the AllNamespaces=true to AllNamespaces=false because we thought it could not work due to the namespace scope operator with role instead of cluster-role, so better have a supposed correct value in the CSV instead of using default value
• Updated the MultiNamespace=false to MultiNamespace=true, because it is supposed that MultiNamespace mode uses a role for every namespace (instead of using a cluster-role), so we thought this setup was the correct one for managing CRs on different namespaces

  installModes:
  - supported: true
    type: OwnNamespace
  - supported: true
    type: SingleNamespace
  - supported: true
    type: MultiNamespace
  - supported: false
    type: AllNamespaces

However:

• The MultiNamespace=true never worked fine due to a bug in operator-sdk:v1.4.0 (the one used), we reported that bug at https://github.com/operator-framework/operator-sdk/issues/4647, which was fixed on https://github.com/operator-framework/operator-sdk/pull/4850 (Fixed on release operator-sdk:v1.6.4 https://github.com/operator-framework/operator-sdk/releases/tag/v1.6.4), but we never upgraded the operator-sdk version
• If we understood correctly, you are confirming that you were successfully using the AllNamespaces=true despite it is a namespace-scope-operator? If the answer is yes, we misunderstood OLM, and maybe OLM knows how to handle the permissions of every installMode independently from what is specified at the operator (role/cluster-role), or maybe just create a role on every namespace of a cluster...

So, after the explanation regarding the intention of the differentinstallModes... (which might be wrong from our side), @bukovjanmic can you confirm you were using successfully AllNamespaces=true, so we might open a PR to operatorhub (https://github.com/redhat-openshift-ecosystem/community-operators-prod/blob/0a7223e07bd4b2d05ec904545ec0daa23579b9bd/operators/prometheus-exporter-operator/0.3.4/manifests/prometheus-exporter-operator.clusterserviceversion.yaml#L246) in order to fix the CSV from current v0.3.4 release?

[bukovjanmic]

Yes, we installed the operator (the 0.2.4 version) through OLM, Openshift 4.6 web console, we used "All Namespaces" for Managed namespaces and as far as we tested, the operator worked correctly (we tested the PostgreSQL exporter).

[slopezz]

Thanks for confirming it @bukovjanmic , going to open a PR to fix the v0.3.4 CSV https://github.com/redhat-openshift-ecosystem/community-operators-prod if they let me modify an existing version. If not, will generate a new release.

[slopezz]

PR opened https://github.com/redhat-openshift-ecosystem/community-operators-prod/pull/374

[slopezz]

@bukovjanmic PR https://github.com/redhat-openshift-ecosystem/community-operators-prod/pull/374 was merged 2 hours ago, and they confirmed the operator is rebuild after 30-60 minutes after merge occur, so maybe operator should be available now.

Can you please confirm if it is available with AllNamespaces=true and if it works as expected?

[bukovjanmic]

Yes, it is available, I installed it and it seems to work normally - it reconciled an existing PostgreSQL exporter and I also tried to create a new one, which worked as expected.

The only issue is that we had to reinstall it (uninstall and install again) as the existing installation through OLM failed automatic upgrade (because of inability to serve All namespaces) and I am not sure if it tries again sometime - did not want to wait.

[slopezz]

Thanks for confirming @bukovjanmic, the failure on the automatic upgrade is expected due to lots of changes required for https://github.com/3scale-ops/prometheus-exporter-operator/releases/tag/v0.3.0 (we encourage to unistall first and then install it again), which implies an upgrade of operator-sdk from v0 to v1, with lots of major changes involving changes on the name of the operator resources or API version changes...

Going to close the issue if resolved, don't hesitate to re-open if it is not really solved, or open a new one in case you detect any other thing.

In the mean time we are going to work on a new operator-sdk upgrade which for example fixes the MultiNamespace support.