Honoring an optional `spec.version` field in the `Operator` API

[joelanford]

This issue should be closed when a demo recording is posted to the #olm-dev kubernetes slack channel that follows the below script:

Demo Script:

1. Install operator-controller from the main branch or its most recently tagged release using operator-controller's standard install script and manifest.
2. Create a Catalog object referencing quay.io/operatorhubio/catalog:latest
3. Wait until the catalog is successfully unpacked.
4. Create an Operator object referencing package prometheus with version 0.32.0
5. Show that a BundleDeployment gets created and references the bundle image quay.io/operatorhubio/prometheus@sha256:14f75077f01feab351f7a046ccfcff6ad357bed2393048d0f6a41f6e64c63278
6. Edit the Operator object and change the version to 0.37.0
7. Show that the existing BundleDeployment is updated to reflect a new bundle image reference with quay.io/operatorhubio/prometheus@sha256:3e281e587de3d03011440685fc4fb782672beab044c1ebadc42788ce05a21c35
8. Edit the Operator object and remove the version specification.
9. Show that the existing BundleDeployment is updated to reflect a new bundle image reference with the highest semver bundle defined in the package (as of 4/5/23, that version is 0.47.0): quay.io/operatorhubio/prometheus@sha256:5b04c49d8d3eff6a338b56ec90bdf491d501fe301c9cdfb740e5bff6769a21ed
10. Edit the Operator object and set the version to 3.0.0.
11. Show the the Operator object has its status updated to reflect that the specified version is not available. Also show that the BundleDeployment is still present and remains at version 0.47.0.
12. Delete the Operator objects.
13. Show that no bundle deployment objects remain.

Related Issues:

• Add .spec.version #142

[tmshort]

Behavior counterpoint:

8. Edit the Operator object and remove the version specification.
9. Show that the existing BundleDeployment is updated to reflect a new bundle image reference with the highest semver bundle defined in the package (as of 4/5/23, that version is 0.47.0): quay.io/operatorhubio/prometheus@sha256:5b04c49d8d3eff6a338b56ec90bdf491d501fe301c9cdfb740e5bff6769a21ed

One could posit that with no version specified, then any version would match the specification. Thus the version would not change. This is different than I specified, but it also makes sense. Upon initial creation, OLMv1 picks a version, which just happens to be latest. And it stays there until the version field is updated to something else.

The behavior would be "latest unless already installed".

[tmshort]

Alternatively, if no version is specified, nothing is done; thus making version mandatory.

[joelanford]

One could posit that with no version specified, then any version would match the specification.

Yes, I agree, and that's actually how it works today. It's any version that meets the constraints of the global resolution, with preference given to higher semver versions. It just so happens today that we have not yet implemented any other APIs that would cause the resolver to look beyond the most preferred version.

Thus the version would not change [...] And it stays there until the version field is updated to something else.

Theoretically, in this model it would also need to change if some other constraint needs the next version.

What this would likely boil down to is that when we generate the resolver input, we list the currently installed version as the highest priority, and then proceed with the remaining versions sorted by semver descending.

Alternatively, if no version is specified, nothing is done; thus making version mandatory.

Yes, but in this case, it would be a poor UX for the system to even accept an object that doesn't specify the version. Which is why we'd mark it as required in the OpenAPI schema of the CRD.

[joelanford]

@tmshort Can we take this convo to a separate issue or discussion? I don't want to distract or confuse the scope of this particular iteration.

[tmshort]

@joelanford #164