As discussed in rhbz#2030186, the ClusterVersion CRD includes requirements like the ^[A-Za-z]([A-Za-z0-9_,:]*[A-Za-z0-9_])?$ check on status.conditionalUpdates.conditions.reason, which we inherit from k8s.io/apimachinery/pkg/apis/meta/v1. The UX where ClusterVersion goes Available=False and subsequently sets off ClusterOperatorDown and wakes the cluster-admin at midnight is not great. But the chance of the graph-data admin flubs their risk names badly enough to fail the regexp is also small. Weighing the poor UX against the low chance of hitting that poor UX, we've decided not to try and copy the API-server's validation up into the cluster-version operator. But we might want to copy some of the API-server's validation up into our graph-data validator. This spike is about filling in a plan there. Some initial options:

a. Decide we're unlikely to break this, and leave it without presubmit coverage. CCXDEV-6495, once we get that, will help us notice and recover, but probably not before the critical ClusterOperatorDown fires after 10m and wakes up cluster-admins.

b. Translate some/all of the CRD's validations into Python and add them to validate-blocked-edges.py. This would give us quick, convenient coverage, but with the maintenance cost of tracking upstream validation and keeping our translation free of bugs/divergence.

c. Launch some kind of e2e that points a real CVO and Kube-API-server at the candidate blocked edge. This gives us the same coverage as (b) with less maintenance burden but higher CI cost and latency. We're already somewhat concerned about graph-data presubmit latency in OTA-255, and it will be hard to hit our ~hour or two PR-opened-to-clusters-notice targets if we spend ~40m launching a cluster to run a presubmit.

d. Other ideas?