Normal Description of problem:
it looks like an explicit check for the type change slipped through the cracks. I think this is one that we should have and is pretty low-effort to add.
Actual results:
message: 'validating upgrade for CRD "nginxolm75123s.cache.example.com" failed: CustomResourceDefinition nginxolm75123s.cache.example.com failed upgrade safety validation. "ChangeValidator" validation failed: version "v1alpha1", field "^.spec.field" has unknown change, refusing to determine that change is safe'
It is considered a breaking change to update the type of a field when upgrading a CRD. We currently do not have an explicit check for this type of change so we get an output similar to:
message: 'validating upgrade for CRD "nginxolm75123s.cache.example.com" failed: CustomResourceDefinition nginxolm75123s.cache.example.com failed upgrade safety validation. "ChangeValidator" validation failed: version "v1alpha1", field "^.spec.field" has unknown change, refusing to determine that change is safe'
We should add a new change validation that explicitly handles this case to improve the UX in identifying the exact reason why a CRD upgrade was rejected and help users make better informed decisions as to if this is a change they are comfortable with going through on their cluster.
This is not a v1.0.0 blocker as it is a QoL improvement and the existing pre-flight check fails closed on an unrecognized change so we aren't causing any harm to a user's cluster with the current state of the check.