When reconciling manifests, CVO uses two kinds of handlers: typed handlers for Kinds that we expect to handle in CVO, and a generic, unstructured handler that is able to read and reconcile resources of any remaining resource Kind, to be able to handle any manifest component developers include in the release payload.

Long-term, this approach causes problems like the following:

1. There is no friction for cluster operator developers to let CVO handle resources that should be managed by their cluster operator instead - they just drop their manifest for the CVO to pick it up, and the unstructured handler will always try to handle it, leading to incorrect responsibility layering in OCP
2. The generic reconciliation procedure results in subtle bugs, like hot-looping as Kinds evolve (and their corresponding manifests are not updated)
3. It is impossible to "drop" support in CVO for e.g. a deprecated version of an API. If we remove the explicit support for the given GroupVersionKind, the manifest that uses the deprecated version just starts to be handled by the unstructured handler.

Therefore, we want to consider removing the unstructured handler from CVO, and only handle the manifests of the defined GVK set.

Definition of Done:

• Create an Epic about the work
• Create ticket to block new components / create an allowlist

Open questions to explore

1. Would we want to add logging / metrics about the unstructured handler usage to better understand the patterns?
2. How many Kinds would we need to "get rid of" and how many operator authors would we need to convince to adopt their manifest for their operator?
3. How we would handle "bad" manifests in CVO at runtime? Should we just refuse to reconcile some manifests?
4. How would we surface "bad" manifests to operator authors?
5. Would it be too pricey to maintain all supported GVKs in CVO code without the fallback of the unstructured handler?

Context

trking on Slack:

ah, I'd missed that we handled these with our generic handler. Long-term, I'd like to drop our generic handler, because I imagine it does a bad job of managing types we have put zero thought into

trking analysis of all Kinds present in 4.13.0 candidate release payload

dhurta@redhat.com's fix for a bug caused by a missing defaulting for unstructured handler

Vadim noted that deprecated version API manifest would be handled by unstructured handler