Feature Overview (aka. Goal Summary)  

As a cluster-admin I can use a single command to see all upgrade checklist before I trigger an update. 
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

==============

{}New additions in 2025{}

• MCP status 
  • Check the maxUnavailable 
  • Compare maxUnavailable to the request level or current load level (if above request level) and determine if this is the correct setting
  • Check to see if the MCPs are paused
• Make a note if etcd is backed up 
• Other operators
  • Note which operators are set to manual vs automatic update
  • Check to determine the next update of all OLM based operators

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.

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
• ACM integration
  • Although Operations will use ACM for day 2 operations. Customer Engineering will use cli for patching, updating, precheck etc.

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>