mobs75 opened a new issue, #218: URL: https://github.com/apache/openserverless/issues/218
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.) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
