Epic Goal

OCPSTRAT-1834 is requesting an oc precheck command that helps customers identify potential issues before triggering an OpenShift cluster upgrade. For 4.18, we'd built a tech-preview oc adm upgrade recommend (OTA-1270, product docs) that is in this "Anything I should think about before updating my cluster [to 4.y.z]?" space, and this Epic is about extending that subcommand with alerts to deliver the coverage requested by OCPSTRAT-1834.

Why is this important?

We currently document some manual checks for customer admins to run before launching an update. For example, RFE-5104 is up asking to automate whatever we're hoping customer are supposed to look for vs. critical alerts. But updating the production OpenShift Update Service is complicated, and it's easier to play around in a tech-preview oc subcommand, while we get a better idea of what information is helpful, and which presentation approaches are most accessible. 4.18's OTA-902 / cvo#1907 folded the Upgradeable condition in as a client-side Conditional Update risk, and this Epic proposes to continue in that direction by retrieving update-relevant alerts and folding those in as additional client-side Conditional Update risks.

Scenarios

As a cluster administrator interested in launching an OCP update, I want to run an oc command that talks to me about my next-hop options, including any information related to known regressions with those target releases, and also including any information about things I should consider addressing in my current cluster state.

Dependencies

The initial implementation can be delivered unilaterally by the OTA updates team. The implementation may surface ambiguous or hard-to-actuate alert messages, and those messages will need to be improved by the component team responsible for maintaining that alert. 

Contributing Teams (and contacts)

• Development - OTA
• Documentation - no docs required
• QE - OTA
• PX - OTA
• Others -

Acceptance Criteria

OCPSTRAT-1834 customer is happy

Drawbacks or Risk

Client-side Conditional Update risks are helpful for cluster administrators who use that particular client. But admins who use older oc or who are using the in-cluster web-console and similar will not see risks known only to newer oc. If we can clearly tie a particular cluster state to update risk, declaring that risk via the OpenShift Update Service would put the information in front of all cluster administrators, regardless of which update interface they use.

However, trialing update risks client-side in tech-preview oc and then possibly promoting them to risks served by the OpenShift Update Service in the future might help us identify cluster state that's only weakly coupled to update success but still interesting enough to display. Or help us find more accessible ways of displaying that context before putting the message in front of large chunks of the fleet.

Done - Checklist

• CI Testing - Tests are merged and completing successfully
• Documentation - No docs.
• QE - Test scenarios are written and executed successfully.
• Technical Enablement - Slides are complete (if requested by PLM)
• Other