-
Feature
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
-
BU Product Work
-
False
-
-
False
-
100% To Do, 0% In Progress, 0% Done
-
0
-
Backlog Refinement
Feature Overview (aka. Goal Summary)
Create a Update precheck command that helps customers identify potential issues before triggering an OpenShift cluster upgrade, without blocking the upgrade process. This tool aims to reduce upgrade failures and support tickets by surfacing common issues beforehand.
Goals (aka. expected user outcomes)
- Enable users (especially those with limited OpenShift expertise) to identify potential upgrade issues before starting the upgrade
- Reduce the number of failed upgrades and support tickets
- Provide clear, actionable information about cluster state relevant to upgrades
- Help customers make informed decisions about when to initiate upgrades
Requirements (aka. Acceptance Criteria):
- Check Pod Disruption Budgets (PDBs):
- Identify existing PDBs that might impact the upgrade
- Display information about PDBs in a way that's understandable to users with limited Kubernetes experience
- workaround - Check DVO PDB checks
- Image Registry Access Verification:
- Validate access to required image repositories
- Pre-check ability to pull images needed for the upgrade
- Verify connectivity to public registries or repository of choice
- workaround : Image pinning GA
- Node Health Verification:
- Check for unavailable nodes
- Identify nodes in maintenance mode
- Detect unscheduled nodes
- Verify overall node health status
- Core Platform Component Health:
- Verify health of control plane workloads
- Check core platform operators' health
- Alert Analysis:
- List any active critical alerts
- Display relevant warning alerts
- Focus on alerts that could impact upgrade success
- Version-Specific Checks:
- Include checks specific to the target upgrade version
- Verify requirements for new features or changes between versions
- Check networking-related requirements (e.g., SDN to OVN migrations)
- Output Requirements:
- Provide clear, understandable output for users without deep OpenShift knowledge
- Don't block upgrades even if issues are found
- Present information in an easily digestible format
Anyone reviewing this Feature needs to know which deployment configurations that the Feature will apply to (or not) once it's been completed. Describe specific needs (or indicate N/A) for each of the following deployment scenarios. For specific configurations that are out-of-scope for a given release, ensure you provide the OCPSTRAT (for the future to be supported configuration) as well.
Deployment considerations | List applicable specific needs (N/A = not applicable) |
Self-managed, managed, or both | Self-managed |
Classic (standalone cluster) | standalone |
Hosted control planes | |
Multi node, Compact (three node), or Single node (SNO), or all | All |
Connected / Restricted Network | All |
Architectures, e.g. x86_x64, ARM (aarch64), IBM Power (ppc64le), and IBM Z (s390x) | All |
Operator compatibility | |
Backport needed (list applicable versions) | |
UI need (e.g. OpenShift Console, dynamic plugin, OCM) | |
Other (please specify) |
Use Cases (Optional):
Include use case diagrams, main success scenarios, alternative flow scenarios. Initial completion during Refinement status.
<your text here>
Questions to Answer (Optional):
Include a list of refinement / architectural questions that may need to be answered before coding can begin. Initial completion during Refinement status.
<your text here>
Out of Scope
- Blocking upgrade execution
- Checking entire cluster state
- Verifying non-platform workloads
- Automated issue resolution
- Comprehensive cluster health checking
- Extensive operator compatibility verification beyond core platform
Background
Provide any additional context is needed to frame the feature. Initial completion during Refinement status.
<your text here>
Customer Considerations
- Target users may have limited Kubernetes/OpenShift expertise
- Many users coming from VMware background
- Customers often don't have TAM or premium support
- Users may not be familiar with platform-specific concepts
- Need to accommodate users who prefer not to read extensive documentation
Documentation Considerations
Add docs for precheck command
Interoperability Considerations
Which other projects, including ROSA/OSD/ARO, and versions in our portfolio does this feature impact? What interoperability test scenarios should be factored by the layered products? Initial completion during Refinement status.
<your text here>
- is cloned by
-
OCPSTRAT-1850 OCP Update Recommend command to improve update experience -Tech Preview
- Release Pending