3rd party Operator Catalog references change during an OCP Upgrade

Goal: Enable changing Operator catalog as part of a platform upgrade to avoid that clusters upgrades leave Operator installations in unsupported states or without a continued update path.

Background: Operator compatibility with the underlying platform can be expressed in various ways, one of which is: catalogs that are specifically created for a particular platform release, e.g. OpenShift 4.5 vs. OpenShift 4.6. For on-board OCP Operator the change of these catalogs is automatic (controlled by CVO). Such control is missing for custom, 3rd party catalogs.

Why is this important: 3rd party Operators have a similar requirement to automatically upgrade the Operator if the underlying platform get upgraded, to ensure users are left with a compatible and supported Operator install. Advanced solutions are possible, e.g. a catalog of catalogs via declarative config that automatically determine which is the correct catalog, new APIs that stamp out CatalogSource objects or proxies at the registry side serving the catalog images. But simple templating of the URL spec in a CatalogSource goes a long way as a stop gap that potentially solves 80% of the use cases we see today.

Example:

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: dynamic-catalog
  namespace: olm
  annotations:
    olm.catalogImageTemplate: "quay.io/kube-release-v{kube_major_version}/catalog:v{kube_major_version}.{kube_minor_version}"
spec:
  sourceType: grpc
  image: quay.io/kube-release-v1/catalog:v1.20
  displayName: My always up2date Catalog
  publisher: Red Hat

 
The image reference would resolve to quay.io/kube-release-v1/catalog:v1.19 for a cluster running Kubernetes 1.19 and would render quay.io/kube-release-v1/catalog:v1.20 for Kubernetes 1.20.
when the template value is unobtainable, the CatalogSource status should include messages such as Cannot construct catalog image reference, variable "kube_major_version" couldn't be resolved.

Acceptance criteria:

• dynamic catalog references enabled by variables im the catalog image URL spec
• supported variables include kubernetes version (major, minor, e.g. 1.22)
• usage of unresolvable variables in the catalog image URL spec results in the catalog operator stop reconciliation of the CatalogSource and set it into a human-readable error condition
• any change in the resolved / rendered image URL spec leads to a catalog update (switch to the new image)