doc: catalog scoping #171
doc: catalog scoping #171
Conversation
Signed-off-by: Daniel Sover <[email protected]>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: exdx The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
| @@ -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. | |||
There was a problem hiding this comment.
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"?
There was a problem hiding this comment.
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.
| ### 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. | ||
|
|
||
| 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. |
There was a problem hiding this comment.
The global namespace is configurable via the
OPERATOR_NAMESPACEenvironment 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.
| 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. | ||
|
|
||
| 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. | ||
|
|
There was a problem hiding this comment.
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: CatalogSourcesUnhealthyThe 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 ...".
|
@exdx: PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
openshift-ci
bot
added
the
needs-rebase
Signed-off-by: Daniel Sover [email protected]
Closes #170