# OLM-1950 - Operator OpenShift Release Compatibility

This is an attempt to groom [OLM-1950](https://issues.redhat.com/browse/OLM-1950) into a set of pointed stories, deliverable by the OLM team in OCP 4.8, that satisfy the the primary goals detailed below.

## Goals

- define a standard way to specify an operator's compatibility with OpenShift
- on cluster, mark operators that are incompatible with the cluster's current or next minor version
- on cluster, prevent operators that are incompatible with the current cluster version from being installed or upgraded to
- on cluster, block cluster upgrade while any incompatible operators are still installed

## Open Questions

- ~~can a cluster upgrade skip minor versions? e.g. 4.8 -> 4.10~~
- A: minor upgrades always occur serially on the control plane
- OLM's upstream/downstream split is happening concurrently, and this epic adds downstream-only bits, should we deliver this to the downstream repos only?

## General Concerns

- "fail open" means operators that don't specify compatibility will not block cluster upgrades
- risk: if the operator is actually incompatible, we end up breaking clusters by upgrading
- reason: we can't expect all operator authors to specify compatibility
- mitigation: surface warning when installed operators don't specify compatibility
- [further reading](https://hackmd.io/9dRLEDRmQw2Pt2mnMdxvGA)
- e2e testing for blocking upgrades

## MVP

The minimum set of features for this epic to provide **any** value in 4.8:

- an operator author can specify the maximum version of OpenShift that their operator is compatible with
- OpenShift cluster upgrades will be blocked while Y+1 incompatible operators are installed
- a cluster admin has a way to determine which operators are blocking an OpenShift upgrade

**Assumptions:**

- Operator authors for Red Hat indexes can add properties to the metadata of their bundles

**Implementation:**

1. Implement explicit properties for bundles so that `maxOpenShiftVersion` can be set by operator authors
- requires changes to `opm` index building
2. Add logic to OLM that:
- keeps its ClusterOperator in a not upgradeable state until no operator exists with `maxOpenShiftVersion < cluster's minor version +1`
- denotes incompatibilities on OperatorConditions

## Stories

### [OLM-2027](https://issues.redhat.com/browse/OLM-2027) - Add warning for v1beta1 CRDs in a bundle

As written: `opm` warns when v1beta1 CRDs are present when creating/validating a bundle.

**Concerns:**

- this couples `opm` to specific versions of k8s/openshift
- this check belongs to domain of the bundle/catalog author, who determines which k8s/openshift versions their operator should run on

**Course Correction:**

- pipelines should have a story for scanning the content of a bundle and applying the `maxOpenShiftVersion` property when v1beta1 CRDs are encountered
- **remove/obsolete story**

### [OLM-2074](https://issues.redhat.com/browse/OLM-2074) - OLM blocks minor OCP upgrades on incompatible OCP versions (MVP story)

**Point Recommendation:** 5

**Concerns:**

N/A

**Course Correction:**

N/A

### [OLM-2075](https://issues.redhat.com/browse/OLM-2075) - Update operator/OCP compatibility in an index without republishing a bundle

**Concerns:**

- blocked by declarative config epic, which is currently red
- is subsumed by the declarative config epic
- there's no workflow for how this would be used by index maintainers (at Red Hat)
- orthogonal to epic goals

**Course Correction:**

- **remove/obsolete story**

### [OLM-2076](https://issues.redhat.com/browse/OLM-2076) - OLM doesn't install operators on unsupported OpenShift versions

**Point Recommendation:** 3

**Questions:**

- if Red Hat pipelines detect compatibility when adding content, and they ship per-version catalogs, can't they also ensure incompatible content is never shipped to a cluster?

**Concerns:**

- adding OpenShift specific logic to the resolver

**Course Correction:**

N/A

## Missing Stories

### As an operator author, I can explicitly specify properties in my operator's bundle (MVP Story)

EP: https://github.com/operator-framework/enhancements/pull/61

Questions:

- what epic does this belong to?