Safe Upgrades: From Tombstones to Recommendations
summary
OpenShift adds Conditional Updates by annotating the Cincinnati update graph with metadata and a PromQL self-check so each cluster evaluates if a release actually affects its configuration; non-recommended edges stay hidden behind a toggle but remain upgradeable with an extra confirmation. The Cluster Version Operator still uses the update graph and payload images, and Red Hat used this recall mechanism for about 24 issues over three releases, reducing broad blocks but exposing UX gaps around disappearing recommendations.
AI-written summary · about
chapters (13)
- 0:00OpenShift OTA team intro
- 2:10How OpenShift updates work
- 8:35Real-world upgrade challenges
- 14:54Smarter upgrade recommendations
- 17:22Conditional updates and PromQL
- 20:09Success after one year
- 21:55User feedback and challenges
- 24:41Non-recommended paths UX
- 26:08Future upgrade decision plans
- 29:29Q&A: Missing metrics
- 32:20Q&A: Disappearing upgrade options
- 33:58Q&A: Staging upgrades
- 35:27Closing remarks
related talks
14mImproving OpenShift Cluster Updates, Step by Step
46mEnd-Users Won't Even Notice, Painless Kubernetes Upgrades
50mOps issues
43mUpgrade Yourself to the Business Class
06mNever ever upgrade
32mOptimizing your Hybrid Cloud Operating System Experience
35mHandling Risky Business: Cluster Upgrades
56mComparison of Linux Software Update Technologies