search

operator-framework / operator-controller

A new and improved management framework for extending Kubernetes with Operators
https://operator-framework.github.io/operator-controller/
Apache License 2.0
70 stars 54 forks source link

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

Closed joelanford closed 11 months ago

joelanford commented 1 year ago

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

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 commented 1 year ago

I started working on this and noticed an issue with the cache for the catalog being stale. I created https://github.com/operator-framework/operator-controller/issues/528 for it