Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

doc: catalog scoping #171

Closed
wants to merge 1 commit into from
Closed

doc: catalog scoping #171

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions content/en/docs/Tasks/make-index-available-on-cluster.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -27,6 +27,11 @@ spec:
interval: 10m
```

### Catalog scoping
By default, a CatalogSource is scoped to the namespace in which it is created in. For example, a CatalogSource in namespace `A` can only be used in dependency resolution for subscriptions that originate in namespace `A` as well. A subscription in another namespace that references the CatalogSource in `A` will not be able to use the catalog contents for dependency resolution. This provides some basic multitenancy: CatalogSource in one namespace do not interfere with CatalogSource in another.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the cognitive load needed to grasp the phrase dependency resolution necessary for this section of the doc? How about rephrasing it to something like "operators in a CatalogSource in namespace A can only be subscribed to from namespace A, i.e a subscription created in namespace B for an operator from the CatalogSource in namespace A will fail"?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'd largely agree here with Anik - it seems sufficient to me to explain that CatalogSource(es) are scoped in the namespace they've been created in, and in order to install a namespaced-scoped Operator that's defined in that CatalogSource, you must also create that Subscription in the same namespace as the CatalogSource definition. The only caveat being the olm namespace acting as a global namespace for dependency resolution.


However, there is one special namespace, by default the `olm` namespace, which acts as a global catalog namespace. CatalogSources in this namespace can be used for dependency resolution in any other namespace. Installing a catalog in the `olm` namespace will make it available as a subscription target for any namespace on the cluster. The global namespace is configurable via the `OPERATOR_NAMESPACE` environment variable on the OLM operator deployment spec.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The global namespace is configurable via the OPERATOR_NAMESPACE environment variable on the OLM operator deployment spec.

Maybe worth extending this sentence with an example. We have to assume readers of this doc do not know how to configure env variable for a deployment.


Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mainly just a follow-up from the existing issue on upstream OLM - is it worth adding a troubleshooting-esq section either here, or in the dedicate troubleshooting index, around resolving dependency resolution errors in the context of how CatalogSource(es) are scoped?

The original example in the issue comes to mind:

...
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

The messaging around that example would be likely be a more cleaned version of "if you see the following status condition message, check out the catalog source scoping document ...".

### Explanation of spec.updateStrategy

It is possible to configure the `CatalogSource` to poll a source, such as an image registry, to check whether the catalog source pod should be updated. A common use case would be pushing new bundles to the same catalog source tag, and seeing updated operators from those bundles being installed in the cluster. Currently polling is only implemented for image-based catalogs that serve bundles over gRPC.
Expand Down