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

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[camilamacedo86]

OK. I will try this config.
thank you

[camilamacedo86]

Hi @JoelSpeed,

Thank you for the clarification about using WhenRequired for custom resources. I’ve updated our configuration accordingly:

lintersConfig:
  optionalfields:
    pointers:
      preference: WhenRequired

However, we’re still running into issues with Status fields in scaffolded CRDs:

// Status defines the observed state
// +optional
Status MyResourceStatus `json:"status,omitzero"`

Error:
optionalfields: field Status has a valid zero value ({}), but the validation is not complete (e.g. min properties/adding required fields). The field should be a pointer to allow the zero value to be set.

I will open an issue with all cases sicne they are related
And we go from there closing this one.

[camilamacedo86]

Move to here since all is related; #192
(to better track this one)