In order to make OLMv1 more than just a toy project upstream, we need to put effort into making it actually upgradeable in upstream Kubernetes clusters.
At a minimum, this would entail:
Documentation that lists valid upgrade paths
Testing, that provides confidence for making changes that will not break upgrades (and perhaps that could even automatically report valid upgrade edges automatically)
A release process that makes new releases available in a consumable and consistent way.
If I'm dreaming big, I think this could look like:
We design and deliver the following as prerequisites:
operator-framework/catalogd#271
856
657
597
390
962
We start shipping OLMv1 as a helm chart
We start shipping an FBC catalog for OLMv1, containing edges verified by our upgrade tests
We implement an installer that can bootstrap an OLMv1 release into a ClusterExtension
We update our upgrade tests to use the bootstrapping mechanism so that we can reuse all of the existing pre-flight checks and health checking built into OLMv1.
In order to make OLMv1 more than just a toy project upstream, we need to put effort into making it actually upgradeable in upstream Kubernetes clusters.
At a minimum, this would entail:
If I'm dreaming big, I think this could look like:
856
657
597
390
962
ClusterExtension