Closed
Description
Background
OLM V0 had a concept of an upgrade graph, which defined linear upgrade graphs that users had to proceed through, learn more here: https://olm.operatorframework.io/docs/concepts/olm-architecture/operator-catalog/creating-an-update-graph/
Story
- As an OLM V1 user, I would like to respect upgrade edges defined by operator authors.
Demo Script:
- Install OLM v1.
- Create an Operator CR that uses the spec.Version field to install operator Foo at version n.
- Wait for the operator Foo to install
- Attempt to change the spec.Version to version m, which is not a supported upgrade edge
- Check that the upgrade fails because it isn't a valid upgrade edge
- Update the spec.Version field to n+1, which is a supported upgrade edge.
- Check that the upgrade proceeds as expected.
Out of Scope
- If operator foo is installed at version n, we will not proceed if the user updates the spec.Version field to a value that could be reached after a series of upgrades. IE: Fail if operator foo is installed at version n and then the user updates the spec.Version field to n+2.
- There is no expectation of reporting available upgrade edges in the operator CR Status.
Things to consider:
- How can we map installed content to catalog content
- How can we respect bundle replaces fields
- How can we respect bundle skips fields
- How can Variable source that considers installed content
Proposed issues:
- Introduce variable source for installed bundles
- Collect "installed" bundles
-- @perdasilva proposed an BundleDeployment CR annotation that links installed content to a catalog
-- Feed "installed" bundles into resolver - Introduce variable source for "upgrade edges"
-- Introduce channel constraint
-- Introduce replaces constraint
-- Introduce skips constraint - Is disabled by default, can be enabled using the Feature Gate functionality proposed in Introduce Support for Feature Gates #255
Follow Ups:
- Update the demo script to reference an actual operator and version.
- Create an issue to consider skipRange