ClusterServiceVersion minKubeVersion is not enforced

[cdjohnson]

Bug Report

What did you do?

1. Create a CSV and bundle image with a single operator with spec.minKubeVersion: 1.20.0
2. Add the CSV to a catalog index image
3. Create a CatalogSource
4. Create a Subscription to the operator in the CatalogSource.

What did you expect to see? I expected the operator to be excluded from the update graph based on the constraint, preventing the operator from being selectable as an install option.

What did you see instead? Under which circumstances? The operator is installable and successfully installed regardless of the minKubeVersion being detected.

In the status section of the applied CSV, I do see the following:

  - group: operators.coreos.com
      kind: ClusterServiceVersion
      message: >-
        CSV version requirement not met: minKubeVersion (1.20.0) > server
        version (1.19.0+7070803)
      name: testoperatora.v1.0.0
      status: PresentNotSatisfied
      version: v1alpha1

Environment

• operator-lifecycle-manager version: OpenShift 4.6.9

• Kubernetes version information:

  oc version
  Client Version: 4.6.8
  Server Version: 4.6.9
  Kubernetes Version: v1.19.0+7070803

• Kubernetes cluster kind: UPI

Possible Solution None

Additional context None

[ecordell]

The operator is installable and successfully installed regardless of the minKubeVersion being detected.

The operator should be in the Pending state - do you see the CSV in the Succeeded state?

This is more of a known limitation of minKubeVersion (+ a set of other things we only detect once we have the CSV applied) and was part of the reason for the resolver revamp last year and the declarative config this year. I would reframe this as a feature request ("olm shouldn't resolve operators that would fail to run, if that can be detected by metadata"), though it's a feature request that we're finally in a position to do something about.

[dinhxuanvu]

If the CSV is in Pending state, then this is expected behavior. The minKubeVersion doesn't prevent the operator to be installed in the cluster. It only prevents the operator from reaching the Succeeded state and ready to serve.

[cdjohnson]

Sorry, yes, the CSV Is indeed in the Pending state (I'm used to my test pod failing all the time and didn't look closely).

I'm concerned that as products move forward and start to leverage APIs as Kubernetes starts removing them, this will be one of those values that developers will want to leverage to avoid auto-updates from trying to install now-incompatible versions.

In this particular case the operator developer was using minKubeVersion to allow using the new v1 CRD, which isn't available on OCP 4.4.

Maybe the right way to go is to use spec.apiservicedefinitions.required instead? Presumably this is used by the sat solver like spec.customeresourcedefinitionsrequired ...

I'll bring this up for discussion on the olm-dev call on 2/11/2021 to discuss the right way to handle cases where APIs go away.