Bug: optionalfields incorrectly requires pointer for enum-like string field with default

[camilamacedo86]

Bug: optionalfields incorrectly requires pointer for enum-like field with default

The optionalfields rule in kube-api-linter is flagging a field that should be valid:

// +optional
// +kubebuilder:default:=Allow
ConcurrencyPolicy ConcurrencyPolicy `json:"concurrencyPolicy,omitempty"`

Error:

optionalfields: field ConcurrencyPolicy is optional and should be a pointer

However:

• The field has a default (Allow)
• It's not semantically optional (default is always injected)
• It's an enum-style string alias (not a struct or slice)

Upstream Kubernetes APIs (e.g. batch/v1) define similar fields without pointers.

Suggestion

The rule should not require a pointer if:

• The field is a basic or alias type (e.g. string)
• It has +optional and +kubebuilder:default
• The tag includes omitempty

This avoids unnecessary boilerplate and aligns with upstream standards.

[camilamacedo86]

c/c @JoelSpeed

[JoelSpeed]

Are you using the default settings? For the default settings, all optional fields are set to pointers, which is, and always has been the advice from the Kubernetes API conventions for optional fields.

The WhenRequired option is smarter. And would detect when the field actually needs to be a pointer. This was designed for CRDs where openapi validation will check the optionality of fields and therefore the structured client doesn't have to care about it so much.

For Kubebuilder, I think we probably want to recommend the WhenRequired, in this case, it would have said that the field is ok (assuming that "" is not a valid value in the enum marker

[camilamacedo86]

Hi @JoelSpeed

Thank you. Could we not consider the:

rules:
  optionalfields:
    mode: WhenRequired

The default behaviour? Has any reason for the smarter validation not be added by default in the optionalfields

[JoelSpeed]

The behaviour differs depending on whether you are building types for core Kubernetes, or for custom resources. The WhenRequired is the appropriate default option for custom resources, but it does not work for core Kubernetes types.
The Always option works for both core Kubernetes types, and customer resources, but, is sub-optimal for custom resources.

The defaults of KAL will take the approach that is safe for the core Kube types, but i intend in the future to provide a custom-resource specific default configuration somehow