While experimenting with adding a new optional component via the ops config enable --X pattern, I ran into a schema mismatch between fields generated by the CLI and the fields defined in the corresponding CRD's openAPIV3Schema.
On Kubernetes 1.32 (e.g. MicroK8s), this mismatch goes unnoticed — the extra fields are simply ignored. On Kubernetes 1.33+ (e.g. kind), strict CRD validation causes the API server to silently prune any field not defined in the schema during apply/patch, rather than rejecting the request. The resource looks like it applied successfully, but the data is quietly gone, which made this very hard to diagnose.
Workaround x-kubernetes-preserve-unknown-fields: true only works if applied at the exact nested level where the mismatch occurs — applying it at a parent node isn't sufficient.
This seems like a general robustness gap rather than a one-off bug: any future component following the same CLI-writes-fields / CRD-defines-schema pattern could hit the same silent data loss on newer Kubernetes versions. Worth considering either (a) testing CRD schema compatibility against a 1.33+ cluster in CI, not just older versions, or (b) a convention/checklist to keep CLI-generated fields and CRD schemas in sync before release.
(Note: the schema mismatch is in the operator submodule — CRD at olaris-op/deploy/nuvolaris-permissions/whisk-crd.yaml — but filing here since sub-repo issues are disabled.)
While experimenting with adding a new optional component via the
ops config enable --Xpattern, I ran into a schema mismatch between fields generated by the CLI and the fields defined in the corresponding CRD'sopenAPIV3Schema.On Kubernetes 1.32 (e.g. MicroK8s), this mismatch goes unnoticed — the extra fields are simply ignored. On Kubernetes 1.33+ (e.g. kind), strict CRD validation causes the API server to silently prune any field not defined in the schema during apply/patch, rather than rejecting the request. The resource looks like it applied successfully, but the data is quietly gone, which made this very hard to diagnose.
Workaround
x-kubernetes-preserve-unknown-fields: trueonly works if applied at the exact nested level where the mismatch occurs — applying it at a parent node isn't sufficient.This seems like a general robustness gap rather than a one-off bug: any future component following the same CLI-writes-fields / CRD-defines-schema pattern could hit the same silent data loss on newer Kubernetes versions. Worth considering either (a) testing CRD schema compatibility against a 1.33+ cluster in CI, not just older versions, or (b) a convention/checklist to keep CLI-generated fields and CRD schemas in sync before release.
(Note: the schema mismatch is in the operator submodule — CRD at
olaris-op/deploy/nuvolaris-permissions/whisk-crd.yaml— but filing here since sub-repo issues are disabled.)