OCPSTRAT-2118 is hoping we'll eventually grow ClusterVersion spec properties in this space. But to collect feedback on the general idea, this ticket is asking to stub in some initial work in the recommend command. Without OCPSTRAT-2118's API changes, all of the cluster-side risks will get lumped into a few coarse slugs:

• Failing, for all Failing=True conditions.
• Progressing, for re-targeting from an existing, in-progress Progressing=True update.
• ConditionalUpdateRisk, for all conditional update risks or Upgradeable=False conditions

The alert checks that are currently implemented client-side in recommend will be slugged by their alert name, allowing an admin to accept the risk of PodDisruptionBudgetLimit. But there would not be the ability to accept the risk of PodDisruptionBudgetLimit(namespace=...,poddisruptionbudget=...) while rejecting other PodDisruptionBudgetLimit. If that kind of granularity seems interesting, we can try to figure out how to build it in follow-up work. Similarly, there would not be a way to accept "all PDB alerts", the admin would have to explicitly accept both PodDisruptionBudgetLimit and PodDisruptionBudgetAtLimit.

When --version was used and the client found anything interesting that wasn't accepted, the client would exit 1. If the client was able to successfully generate a report, and any interesting conditions were all in the admin-accepted slugs, the client would exit 0.

This whole thing will initially be gated behind an OC_ENABLE_CMD_UPGRADE_RECOMMEND_ACCEPTED_RISKS environment variable feature gate, while we collect feedback.