From SDK 1.17.0 release CRD using v1beta1 requires preserveUnknownFields: false to pass in the validations

[camilamacedo86]

Bug Report

From SDK 1.17.0 release CRD using v1beta1 requires preserveUnknownFields: false to pass in the validations
We need to understand why.

• Is some dependence that was added to the operator-framework/api?
• Should the preserveUnknownFields: false been set before and the checks were not raising the error?
• Should we really fail in this scenario where the preserveUnknownFields: false is not set?

What did you do?

Following the steps to reproduce the issue.

1. Create the mock project with v1beta1 and a bundle for it: ( you can use the master branch or the latest release 1.19.0 )

$ mkdir test
$ cd test
$ go mod init test
go: creating new go.mod: module test

$ operator-sdk init
$ operator-sdk create api --group crew --version v1 --kind Admiral --controller=true --resource=true --namespaced=false --make=false --crd-version=v1beta1
$ go mod tidy

$ make bundle
…
operator-sdk bundle validate ./bundle
INFO[0000] All validation tests have completed successfully

2. Now, edit the CRD to remove the attributed requires preserveUnknownFields: false

$ vim bundle/manifests/crew.my.domain_admirals.yaml

3. Run bundle validate again:

$ operator-sdk bundle validate ./bundle --select-optional suite=operatorframework 
ERRO[0000] Error: Field spec.preserveUnknownFields, Value 0xc000c31ac0: spec.preserveUnknownFields: Invalid value: true: cannot set to true, set x-preserve-unknown-fields to true in spec.versions[*].schema instead 

See that the error spec.preserveUnknownFields: Invalid value: true: cannot set to true, set x-preserve-unknown-fields to true in spec.versions[*].schema instead will be raised.

4. Now, do the same check using SDK 1.16.0:

$ git fetch --all --tags
$ git checkout tags/v1.16.0 -b v1.16.0
$ make install 
$ operator-sdk version 

You will see that the error spec.preserveUnknownFields: Invalid value: true: cannot set to true, set x-preserve-unknown-fields to true in spec.versions[*].schema instead is NOT raised.

What did you expect to see?

What did you see instead? Under which circumstances?

Environment

Operator type:

Kubernetes cluster type:

$ operator-sdk version

$ go version (if language is Go)

$ kubectl version

Possible Solution

Additional context

[camilamacedo86]

@ryantking @J0zi @mvalarh ^

[cbandy]

Comparing SDK v1.16.0 to v1.17.0 shows the following change to imports:

-	github.com/operator-framework/api v0.11.1-0.20220110184307-ff6b5ebe3c25
+	github.com/operator-framework/api v0.11.2-0.20220118170607-6b187a1d0908

Comparing those SHAs in API includes the following commit which changes CRD validation:

• operator-framework/api@12a70c0#diff-a6ba9212277115e9546b6820675083d6921798c2f179f225664cffa98208e34c

[camilamacedo86]

The community guess is that is related to the fact of SDK/API be upgraded to use k8s 1.23 as well.
See: https://github.com/kubernetes/kubernetes/blob/v1.23.0/staging/src/k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/validation/validation.go#L1451

[jmrodri]

It was definitely due to a k8s update. I know we were removing them after the update and had to add a FAQ https://sdk.operatorframework.io/docs/faqs/#preserve-the-preserveunknownfields-in-your-crds

[jmrodri]

@camilamacedo86 I'm not sure what the exact issue is you are trying to outline.

[camilamacedo86]

Hi @jmrodri,

What is the problem?

After we bump the k8s api to 1.23 on operator-framework/api, the behaviour change and begin to require preserveUnknownFields: false by looking at that, the change was done in the k8s api, so it shows like a bug fix. We could try to track it out to understand better.

What is the impact?

It only really affects those who want to provide solutions for k8s versions < 1.16 and Openshift < 4.6 (which indeed would be in EOL). On top of that, we should recommend encouraging Operator authors to no more extended use v1beta1 for CRDs since this API was removed with K8s release 1.22 and Openshift 4.9, and we have the k8s 1.24 released already.

Also, the optional flags for building projects with CRD/Webhooks using the API v1beta1 are deprecated on SDK and Kubebuilder. Then, IMO honest, I do not think that it would be too much value to spend time on this issue since we could be working on other ones to add new values or fix bug fixes that have a more significant impact and value for the users.

What seems like the priority of it? Why (IMO) we can close this one

It shows very low priority for the community and project and we can close this one as deferred with:

• The v1beta1 API is no longer offered, and the options to work with are deprecated on the projects
• We do not encourage Operator Authors to use v1beta1 versions
• We highly recommend upgrading their projects to use v1 API instead which has been the default behaviour since SDK release 1.0.0

@cbandy I hope that you do not mind we close this one based on the above cons/pros of we spend this effort on these deprecated features for APIS that indeed are no longer served by k8s.

[jmrodri]

Closing this issue, if @cbandy or @camilamacedo86 think we should revisit this, please add a new comment as to why and reopen.