Should we rename the Operator CRD?

[ncdc]

There is a naming collision between the OLM v0 CRD, operators.operators.coreos.com, and the v1 CRD, operators.operators.operatorframework.io.

Both of these can be referred to as operators. If only one of these CRDs is present in a cluster, kubectl get operators returns instances of that CRD. If both of them are present, however, kubectl get operators will only ever return instances from one of the CRDs. There can be a couple of factors that influence which CRD is associated with operators, and it can vary per cluster and per client.

Long story short, if users have both OLM v0 and v1 installed on a cluster, we'd like to avoid a confusing UX where they aren't necessarily sure if operators refers to the v0 or v1 CRD.

Should we pick a new name for the v1 CRD?

[m1kola]

Some thoughts/questions:

1. I'm struggling to come up with a meaningful name. Any suggestions for alternative names?
2. Also it feels like decision for this depends on the deprecation strategy for OLMv0. Do we have an idea on how and when we want to phase out OLMv0?
3. Is there an alternative solution (without renaming)? First thing which comes to mind (again, depends on deprecation) - can we look into adding a deprecation warning into the OLMv0 CRDs asking users to switch to OLMv1 and play with CRD ordering (can't find any docs on it, but I believe there is a way to influence order for discovery).

[ncdc]

@m1kola

Given that we want to position OLMv0 as "it can apply anything to your cluster"

Did you mean to write v1 here?

maybe Package

Carvel has Package, which we may or may not use in v1

Deprecation message alone is not enough, is it? I'm worried that it will be confusing for users expecting to see OLMv0 operators, but in fact they will be shown OLMv1 ones (or empty list of OLMv1 CRs when they expect non-empty OLMv0 list).

Part of this may depend on our upgrade strategy. For example, maybe we have v1 clone and keep in sync v0 data but in a read-only view mode?

On the other hand - how many humans actually interact with Operator CRs from OLMv0? I would keep this option on the table still.

Good question - anyone have any insight?

@everettraven I do like Extension

[m1kola]

Did you mean to write v1 here?

Yes, Sorry. Updated the original post to avoid further confusion.

[dtfranz]

KubernetesExtension? Or something in that vein (maybe just Extension)?

This is what I was thinking as well. Extension is nice and simple and has the added bonus of being descriptive without as much need for background knowledge as Operator.

[awgreene]

On the other hand - how many humans actually interact with Operator CRs from OLMv0? I would keep this option on the table still.

Good question - anyone have any insight?

@ncdc the OLM v0 operator API is a READ ONLY API which allows users to discover the list of resources created when installing an operator as well as their state, some notes:

• The operator's status.Components field lists the related resources. The Adoption Controller identifies which resources are related to an operator and applies a label which the Operator Controller uses to select resources that appear in the array.
• The operator API's .spec is empty, it a READ-ONLY API.
• The original intent of this API was to be the primary API for interacting with OLM. The "related resource discoverability" feature described above was the first step towards this goal. This was basically abandoned once we decided to work on OLM V1.

[ncdc]

@awgreene thanks for the context and details! But unfortunately that doesn't change the fact that if both v0 and v1 are installed, one of the two APIs will be assigned priority in your local discovery cache. Which one gets priority is nondeterministic. Once assigned, however, it remains consistent. When someone tries to kubectl get operators, they'll either consistently get v0 or v1, but you don't really know which it'll be.

[ncdc]

It was renamed to ClusterExtension.