Re: Co-installation of different versions of an operator

[Daniel Messer]

Hi Marcin,

you touch on an important topic. First, the most current docs are here: https://olm.operatorframework.io/docs/advanced-tasks/operator-scoping-with-operatorgroups/ - we should probably start to update references in GitHub.

To your question: OLM currently allows to install Operators scoped to a single / subset of namespaces and it also allows to do this multiple times, even with different versions of the Operator. In your example, whatever Operator was installed last, A or B, would overwrite the CRDs. Hence you need to use CRD versioning to have Operator vA still be capable of reading and write its CRDs as described here: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/

OperatorGroups are a way to define the scope of an Operator. They set the scope of each Operator installed in the same namespace where the OperatorGroup lives. Scope means: which namespaces is the Operator watching (OLM can managed WATCH_NAMESPACE env var for that) and in which namespaces does the Operator have permissions to watch / read / write / list objects. The individual RBAC is requested by the Operator as part of its metadata and OLM will scope it depending on what the OperatorGroup says.

On top of that there is logic in OLM that avoids that two Operators owning the same APIs are scoped to the same namespaces. This topic is one of the more advanced aspects of OLM because it effectively creates the illusion of tenancy where in Kubernetes there are only global things (CRD). I hope this gets you started though.

Best,
Daniel

On Mon, Apr 19, 2021 at 11:14 AM Marcin Owsiany <mows...@redhat.com> wrote:

Hi,

Hopefully this is a good place to ask about how OLM deals with cluster-scoped resources required by an operator, when installing operators in modes other than AllNamespaces?

To be honest I'm not sure how to ask the question. I read https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/design/operatorgroups.md and I have to admit I was not able to grasp the model. It is not even clear to me whether OLM ever allows more than one operator controller deployment per cluster at all? Perhaps a diagram could make this more clear?

To start with, let me ask this: is it possible to have OLM install operator Foo in namespace A at version vA, and the same operator in namespace B at version vB (say, by referring to different operator distribution channels). If it is possible, then which CRDs (which are cluster-scoped resources) will be installed? Those from vA or vB?

regards,

Marcin

--
You received this message because you are subscribed to the Google Groups "Operator Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to operator-framew...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework/f932cc7b-4379-4f40-a316-00d5a1dd01bbn%40googlegroups.com.

--

Daniel Messer

Product Manager Operator Framework & Quay

Red Hat OpenShift

[Rob Cernich]

On Mon, Apr 19, 2021 at 5:08 AM Daniel Messer <dme...@redhat.com> wrote:

Hi Marcin,

you touch on an important topic. First, the most current docs are here: https://olm.operatorframework.io/docs/advanced-tasks/operator-scoping-with-operatorgroups/ - we should probably start to update references in GitHub.

To your question: OLM currently allows to install Operators scoped to a single / subset of namespaces and it also allows to do this multiple times, even with different versions of the Operator. In your example, whatever Operator was installed last, A or B, would overwrite the CRDs. Hence you need to use CRD versioning to have Operator vA still be capable of reading and write its CRDs as described here: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/

I'm curious about what you'd need to do if conversion was required between resource versions.  Would OLM be managing installation of the converter and configuration of the conversion webhook?

OperatorGroups are a way to define the scope of an Operator. They set the scope of each Operator installed in the same namespace where the OperatorGroup lives. Scope means: which namespaces is the Operator watching (OLM can managed WATCH_NAMESPACE env var for that) and in which namespaces does the Operator have permissions to watch / read / write / list objects. The individual RBAC is requested by the Operator as part of its metadata and OLM will scope it depending on what the OperatorGroup says.

On top of that there is logic in OLM that avoids that two Operators owning the same APIs are scoped to the same namespaces. This topic is one of the more advanced aspects of OLM because it effectively creates the illusion of tenancy where in Kubernetes there are only global things (CRD). I hope this gets you started though.

Best,
Daniel

On Mon, Apr 19, 2021 at 11:14 AM Marcin Owsiany <mows...@redhat.com> wrote:

Hi,

Hopefully this is a good place to ask about how OLM deals with cluster-scoped resources required by an operator, when installing operators in modes other than AllNamespaces?

To be honest I'm not sure how to ask the question. I read https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/design/operatorgroups.md and I have to admit I was not able to grasp the model. It is not even clear to me whether OLM ever allows more than one operator controller deployment per cluster at all? Perhaps a diagram could make this more clear?

To start with, let me ask this: is it possible to have OLM install operator Foo in namespace A at version vA, and the same operator in namespace B at version vB (say, by referring to different operator distribution channels). If it is possible, then which CRDs (which are cluster-scoped resources) will be installed? Those from vA or vB?

regards,

Marcin

--
You received this message because you are subscribed to the Google Groups "Operator Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to operator-framew...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework/f932cc7b-4379-4f40-a316-00d5a1dd01bbn%40googlegroups.com.

--

Daniel Messer

Product Manager Operator Framework & Quay

Red Hat OpenShift

--

You received this message because you are subscribed to the Google Groups "operator-framework-olm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to operator-framework-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework-olm-dev/CAEQM%2BpP9-_V6vvRbrY%2BqWTNxWg-APhYx%3DOW21JyJn24TBwi2DQ%40mail.gmail.com.

[Rob Cernich]

On Tue, Apr 20, 2021 at 12:22 AM Marcin Owsiany <mows...@redhat.com> wrote:

On Mon, 19 Apr 2021 at 23:50, Rob Cernich <rcer...@redhat.com> wrote:

On Mon, Apr 19, 2021 at 5:08 AM Daniel Messer <dme...@redhat.com> wrote:

Hi Marcin,

you touch on an important topic. First, the most current docs are here: https://olm.operatorframework.io/docs/advanced-tasks/operator-scoping-with-operatorgroups/ - we should probably start to update references in GitHub.

To your question: OLM currently allows to install Operators scoped to a single / subset of namespaces and it also allows to do this multiple times, even with different versions of the Operator. In your example, whatever Operator was installed last, A or B, would overwrite the CRDs. Hence you need to use CRD versioning to have Operator vA still be capable of reading and write its CRDs as described here: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/

I'm curious about what you'd need to do if conversion was required between resource versions.  Would OLM be managing installation of the converter and configuration of the conversion webhook?

Looks like it helps with that if you mention the webhook in the CSV: https://olm.operatorframework.io/docs/advanced-tasks/adding-admission-and-conversion-webhooks/

Sorry, was more curious about having multiple instances of the operator: which one gets registered?  what if you have three crd versions, does the operator need to support conversion between all versions?  what if a version has been removed in a newer release? etc.

Marcin