Do an end-to-end demo (Q4 2023)

[joelanford]

It would be great to see something that incorporates all the new features:

• catalogd polling
• Operator.spec.version ranges
• semver-based upgrade constraint policy
• rukpak bundle health

Proposed demo script:

1. Create and push a scratch-based FBC image for demo-catalog:latest containing a bundle v2.0.0-alpha1
2. Create a Catalog pointing to a tag for (1) with a short polling interval (15s)
3. Create an Operator that specifies spec.version: 2.0.x
4. Observe a resolution failure because no bundles exist in that range
   • Highlight: pre-releases are excluded when range implies non-prerelease versions.
5. Update the catalog image with a new bundle, v2.0.0, and push to the same demo-catalog:latest tag.
6. Without modifying the Operator or the Catalog, observe that the resolution succeeds in ~15s and a bundle deployment is created.
   • Highlight: Operator controller reconciles Operators when Catalog polling is enabled and the next poll resolves to a new SHA.
7. Watch the bundle deployment and observe its updates. See the Healthy condition transition from False to True and watch as the Healthy condition message changes to reflect the current health status.
   • Highlight: BD installed condition still tells you whether the BD was successfully applied
   • Highlight: BD healthy condition gives you details about what is going on with the bundle after it has been applied.
8. Update the catalog image with a new bundle v2.1.0, and again push to the same demo-catalog:latest tag
9. Without modifying the Operator or the Catalog, observe no upgrade occurs:
   • Highlight: Operator.spec.version limits versions to the 2.0 z-stream
   • Future work idea: perhaps we can put something on the Operator status that says there are successors available that fall outside the specified version range?
10. Update the catalog image with a new bundle v2.0.1, and again push to the same demo-catalog:latest tag
11. Without modifying the Operator or the Catalog, observe that an upgrade occurs to v2.0.1
    • Highlight: Again, Operator.spec.version limits versions to the 2.0 z-stream. v2.0.1 is in the range. An upgrade proceeds automatically without a change to the Operator object.
12. Update Operator.spec.version to 2.1.x
13. Observe that an upgrade occurs to v2.1.0
    • Highlight: change to Operator results in re-resolution
14. Update the catalog image with a new bundle v3.0.0, and again push to the same demo-catalog:latest tag.
15. Update Operator.spec.version to 3.0.x
16. Observe a resolution failure.
    • Highlight: Operator controller understands semver and assumes that a major version bump could break existing users, and therefore refuses to upgrade.
17. Update Operator to set spec.upgradeConstraintPolicy: Ignore
18. Observe resolution and upgrade to v3.0.0 succeed.
    • Highlight: Administrators have an escape hatch to override OLM's safety mechanisms and allow upgrades across major versions.
19. In a single update, set the Operator with .spec.version: 2.1.x and spec.upgradeConstraintPolicy: Enforce
20. Observe resolution fail
    • Highlight: downgrades are disallowed by default
21. Update Operator to set spec.upgradeConstraintPolicy: Ignore
22. Observe resolution and downgrade to v2.1.0 succeed.
    • Highlight: Administrators have an escape hatch to override OLM's safety mechanisms and allow downgrades

[everettraven]

I started working on this and noticed an issue with the cache for the catalog being stale. I created #528 for it