Add explicit schema for podTemplateSpec.metadata

[jkylling]

Unknown metadata fields are pruned https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#field-pruning
If you change from v1beta CRDs to v1 CRDs the metadata field is pruned and the operator believes that every podSpec is incorrect.
Related to kubernetes-sigs/controller-tools#448

[johscheuer]

Hi, thanks for the PR! I think you have to change in the Makefile the CRD_OPTIONS and add generateEmbeddedObjectMeta=true e.g. to be CRD_OPTIONS ?= "crd:trivialVersions=true,maxDescLen=0,crdVersions=v1,generateEmbeddedObjectMeta=true" otherwise a new run of make will remove it again (that's why CI is complaining). After the change you can just run make clean all and commit the newly generated files. I just noticed that the new field is only available in 0.6.0-beta 🤔

[jkylling]

Thanks! Would it be possible to add unit tests to catch issues like this?

Another tiny annoyance when upgrading the CRDs is that some extra default values are populated (e.g., podSpec.containers[].ports[].protocol was empty, and is now TCP). The operator detects that the last applied podSpec is different from what is now defined in the foundationdbcluster CR and decides to bounce the pod, although the resulting pod is identical (except of metadata.annotations["foundationdb.org/last-applied-spec"]). Would the operator be able to avoid most no-ops like this.

[johscheuer]

Thanks! Would it be possible to add unit tests to catch issues like this?

Using unit-tests will be probably a little bit hard (I would need to check if the default mechanisms are exposed in Kubernetes) but it should be pretty straight forward to add some integration tests for that and I think that most of our tests are actually integration tests. Feel free to add some test cases for that in the PR that would also show/prove that the change actually works like expected.

Another tiny annoyance when upgrading the CRDs is that some extra default values are populated (e.g., podSpec.containers[].ports[].protocol was empty, and is now TCP). The operator detects that the last applied podSpec is different from what is now defined in the foundationdbcluster CR and decides to bounce the pod, although the resulting pod is identical (except of metadata.annotations["foundationdb.org/last-applied-spec"]). Would the operator be able to avoid most no-ops like this.

That should be pretty simple to fix by not using foundationdb.org/last-applied-spec but rather compare the actual specs and ignore all default fields. Let me create an issue for that.

[johscheuer]

The changes look in general good, I'm just not quite sure if we want to use a beta version directly. Let me evaluate that and come back to you.

[johscheuer]

LGTM 👍 Thanks!