What do you want to happen?

Usually there is a tight 1:1 relationship between the controllercontainer image version of the controller and the corresponding CRD which the controller owns.

But sometimes things fail, and the controller is newer/older than its CRD spec in the api-server.

This can lead to hard to debug issues. For example the apiVersion was not changed, but a new optional field was added.

What about adding a hint to client.WithFieldValidation() in kubebuilder?

Some days ago I had a very strange behavior or my controller because the CRD resource was outdated while the controller expected the new schema.

Currently, err := crClient.Patch(...) does not return an error if the Patch (or Update) contains unknown fields. There is a hardly noticeable log on INFO level:

07:50:39 INFO "unknown field "status.newField"" log/warning_handler.go:65

It took me some time to understand the issue: api had changed slightly (without changing the version number), and CRD and controller used different schemas.

After switching to a controller-runtime client with field validation, you get an error if the api-server provides warnings.

This means a line like err := crClient.Patch(...) will result in an error. This error is better because it signals that there is a version mismatch between api-server and controller.

But how could that be integrated?

The change to my controller looks like this: 🌱 Use strict schema validation syself/cluster-api-provider-hetzner

In the kubebuilder git repo there are 34 lines like this: mgr, err := ctrl.NewManager(...).

Changing all these lines to use a strict field validating client makes no sense from my perspective.

We could add a note. But where would be a good place for this?

Extra Labels

No response