-
Spike
-
Resolution: Done
-
Major
-
None
-
None
-
True
-
None
-
False
-
Sprint 226, Sprint 227
-
0
-
0
We're asking the following questions to evaluate whether or not OCPBUGS-2269 warrants changing update recommendations from either the previous X.Y or X.Y.Z. The ultimate goal is to avoid delivering an update which introduces new risk or reduces cluster functionality in any way. Sample answers are provided to give more context and the ImpactStatementRequested label has been added to OCPBUGS-2269. When responding, please remove ImpactStatementRequested and set the ImpactStatementProposed label on OCPBUGS-2269, and move this ticket to Code Review. The expectation is that the OCPBUGS-2269 assignee answers these questions.
Which 4.y.z to 4.y'.z' updates increase vulnerability? Which types of clusters?
- reasoning: This allows us to populate from, to, and matchingRules in conditional update recommendations for "the $SOURCE_RELEASE to $TARGET_RELEASE update is not recommended for clusters like $THIS".
- example: Customers with baremetal clusters who are updating from 4.11.6 to 4.12.0.
What is the impact? Is it serious enough to warrant removing update recommendations?
- reasoning: This allows us to populate name and message in conditional update recommendations for "...because if you update, $THESE_CONDITIONS may cause $THESE_UNFORTUNATE_SYMPTOMS".
- example: Updates will stick on the crash-looping FIXME Deployment. The broken deployment may block further management of FIXME.
How involved is remediation?
- reasoning: This allows administrators who are already vulnerable, or who chose to waive conditional-update risks, to recover their cluster. And even moderately serious impacts might be acceptable if they are easy to mitigate.
- example: Update to a 4.12.z release with a fix, once one of those ships.
- example: Any other possible remediation?
Is this a regression?
- reasoning: Updating between two vulnerable releases may not increase exposure (unless rebooting during the update increases vulnerability, etc.). We only qualify update recommendations if the update increases exposure.
- example: Yes, from any 4.y.z to 4.12.0, with the regression introduced by PR/commit.
- blocks
-
OCPBUGS-2269 "error: No enabled repositories" on upgrade with kernelType: realtime enabled
- Closed
- is triggered by
-
OTA-787 Jira-native UpgradeBlocker/root-cause workflows
- Closed