Nested defaults

[tbarizien]

Hi,

I've been investigating the way defaulting annotations work following a series of strange behaviour occurences in the operators I'm maintaining. We were making a series of small mistakes not following the k8s api conventions regarding optional fields but after fixing this, I'm still wondering about the following use case:

I've made a dummy project to demonstrate the situation.
The type definition I have is following :

type DefaultDemoSpec struct {
	Foo string `json:"foo,omitempty"`

	//+optional
	Car *Car `json:"car,omitempty"`
}

type Car struct {
	//+optional
	//+kubebuilder:default:=50
	Horsepower *int `json:"horsePower,omitempty"`

	//+optional
	//+kubebuilder:default:=4
	Wheels *int `json:"wheels,omitempty"`
}

I want to be able to get default values for my Car struct so that applying the following yaml:

apiVersion: default.example.com/v1
kind: DefaultDemo
metadata:
  name: demo
  namespace: bar-iac-test
spec:
    foo: "test"

Would end up creating the following object:

Spec:
  Car:
    Horse Power:  50
    Wheels:       4
  Foo:            test

The solution I have found is to repeat at least one of the default properties as a default object value above the DefaultDemoSpec.Car definition:

type DefaultDemoSpec struct {
	Foo string `json:"foo,omitempty"`

	//+optional
       //+kubebuilder:default:={wheels:4}
	Car *Car `json:"car,omitempty"`
}

I am not particularly satisfied with this solution as it involves duplicating the defaults. Is there a better way to do this ?
I was hoping annotating it with default:={} would work, but it isn't the case.

Thank you for your time

[camilamacedo86]

Hi @tbarizien,

The omitempty tag tells the Kubernetes API server (and the underlying Go JSON encoder) to omit the field from the output if it's empty. In Kubernetes CRDs, it's common to use omitempty for optional fields to keep the serialized output clean.

When using omitempty in conjunction with default values, I understand that it can lead to some non-intuitive behavior.

Following how I understand that it works:

• With omitempty: If the field is not provided in the YAML (i.e., it's absent), it's considered "empty". So, it gets omitted, and defaulting does not take place for the omitted struct. This is because the CRD mechanism doesn't see the field at all; thus, it doesn't know to look for defaults within the struct.
• Without omitempty: If you remove the omitempty tag and the field is not provided in the YAML, the field will still exist in the serialized output as null or its zero value, depending on the field type. In this case, defaulting for the nested struct fields might be applied, because the containing struct exists even if it's null.

Why it seems that controller-gen works in this way:

• a) Automatically applying defaults to a struct when its fields are all defaulted, but the struct itself is omitted, could lead to unintended consequences or mask errors. If a user truly wants a struct to be defaulted when it's omitted, they have to be explicit about it.

• b) Consider a case where the Car struct has some fields provided and others omitted. In such cases, controller-gen will apply the defaults only to the omitted fields. Having different defaulting behavior for entirely omitted structs vs. partially provided structs could be confusing.

However, if you do not agree with? How to ask to change

See that the markers ( https://book.kubebuilder.io/reference/markers ) are implemented by controller-gen (see the Makefile of your project and the targets make manifest and make generate). So, controller-gen is a binary build from the controller-tools, see: https://github.com/kubernetes-sigs/controller-tools

In this case, I would recommend you open an issue against controller-tools instead to raise a discussion in Kubebuilder.

So, I am closing this one as sorted out.
I hope that helps you out.
However, if you think that should be re-open please feel free to do so and let us know why.