CRD Upgrade Safety preflight checks should check for incompatibility between served versions

[everettraven]

After speaking with folks more familiar with the nuances of CRD management, we need to update the CRD Upgrade Safety preflight check to add a check that for new instances of the CRD only:

• Checks compatibility across all served versions, failing if there is incompatibility
• Fails if incompatibility is found AND no conversion strategy is specified
• Passes if conversion webhook is specified as the conversion strategy

For historical context the previous description of this issue is saved below. It can be used to get clarity on the original concern, but all that is needed for implementation is what is mentioned above.

History

The existing CRD Upgrade Safety preflight checks are limited to checking for breaking changes across existing versions of a CRD (i.e old v1alpha1 vs new v1alpha1), but would not handle the following case:

• CRD Foo v1alpha1 has optional field bar, required field baz and is a stored version
• CRD Foo v1alpha2 is introduced and only has required field bar
• No conversion strategy is specified

Any instances of the v1alpha1 API would be unable to successfully convert to the v1alpha2 API, thus invalidating any instances of v1alpha1 in etcd.

We need to add a validation to the CRD Upgrade Safety preflight check that:

• Checks for breaking changes between existing stored versions (from the old CRD status), and served versions (from the new CRD)
• Returns an error if any breaking changes are found and a conversion strategy is NOT specified
  • If a conversion strategy is specified we could log and/or add an event to warn (similar to OLMv0) or do nothing

[trgeiger]

/assign