Deploy operator in another namespace failed, that catalogsource isn't in olm namespace.

[0xff-dev]

Bug Report

What did you do?
deploy my catalogsource in namespace a, then deploy operator in namespace b, the feedback is targeted catalogsource xxx missing.

What did you expect to see?
operator can be deployed normally.

What did you see instead? Under which circumstances?

status:
  catalogHealth:
  - catalogSourceRef:
      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      name: operatorhubio-catalog
      namespace: olm
      resourceVersion: "195556"
      uid: 097c661b-a753-479e-9661-697e687db658
    healthy: true
    lastUpdated: "2021-06-30T23:36:42Z"
  conditions:
  - lastTransitionTime: "2021-06-30T23:36:42Z"
    message: targeted catalogsource kkk/daas-registry missing
    reason: UnhealthyCatalogSourceFound
    status: "True"
    type: CatalogSourcesUnhealthy

Environment

• operator-lifecycle-manager version:
  0.17.0

• Kubernetes version information:
  {Major:"1", Minor:"18", GitVersion:"v1.18.15"}

• Kubernetes cluster kind:

Possible Solution

operator-lifecycle-manager/pkg/controller/operators/catalog/subscription/reconciler.go

Line 80 in 20ded32

ns := s.Subscription().GetNamespace()

Maybe get namespace from subscription.spec.catalogsrouceNamespace.

[exdx]

The issue is that not all catalogs are globally-scoped. The olm namespace is special -- OLM treats catalogs in this namespace as cluster-scoped for resolution. So one could create a subscription in another namespace for a package in this special namespace. Other namespaces do not behave like this however -- resolution to the catalog is scoped to that single namespace. We are planning to add documentation to address this, and potentially change the design to be more explicit in subsequent versions of OLM.

The special global catalog namespace is also configurable on the olm deployment.

[exdx]

Doc in operator-framework/olm-docs#170

[0xff-dev]

Doc in operator-framework/olm-docs#170

Thanks. It's very useful to me.

[timflannagan]

I'm going to close this out now that we have a dedicated issue on the olm-docs repository as it's attached to the v0.19.0 milestone - I followed-up in the PR that Dan had already created that attempts to get the ball rolling on documenting this behavior. We can track updating the documentation there.