-
Feature
-
Resolution: Unresolved
-
Major
-
None
-
None
-
0% To Do, 0% In Progress, 100% Done
Goal: As we build more features as OLM-shipped Operators, they need to start influencing the cluster's update process so things on both sides don't break.
Benefit hypothesis: This will increase the trust in accepting either a z-stream or an Operator update.
Why is this important: Several different teams are asking for information around this as they know their own APIs or upstream APIs will change over the upcoming releases.
Acceptance criteria:
- Admins are informed and can make a choice about breaking Operators on cluster upgrade
- Operators have tools for preflight checks, because they know best what will break them.
- OLM can also detect Operator updates that would leave the cluster unable to upgrade and block them
- OLM can prevent Operator updates that would render the Operator unusable / unsupported