New Linter: pointeroptional

[yongruilin]

For any field that is a pointer, it should be marked with +optional, +k8s:optional or kubebuilders' optional.
This could provide a clear interface for both client and server for all the pointer fields.

Ref: jpbetz/validation-gen#66

[JoelSpeed]

There are definitely cases in Kube today where they have created required fields that are also pointers. I think these are exceptions and should not have been the case.

I think this makes sense as a rule, but we should make sure that when implementing, if the field is already marked as some sort of required, we do not suggest a fix automatically to add the optional tag and make sure the user makes a choice about to handle the invalid case.

[JoelSpeed]

Contrary to my earlier comment. I think this rule actually doesn't make sense.

We know that there are cases where a field can have a valid zero value, take replicas on a Deployment. Even though this field is required, we want the 0 value to round trip through structured clients, and to force structured clients to make a choice. It is correct for this replicas field to be *int32 and omitempty (see current API conventions docs), and so I don't think we can confidently say pointer fields are optional.

I think what we can say is that pointer fields are either optional, or have a valid and distinct use case for the zero value being different to being unset, which I believe is generally not something that we want to be common.

[sbueringer]

Could it be that pointer/non-pointer and optional/required are entirely orthogonal?

[JoelSpeed]

Could it be that pointer/non-pointer and optional/required are entirely orthogonal?

For custom resources yes, for built-in types, optional fields need to be pointers to be able to distinguish between unset, and set to the zero value because of how the validation is implemented.

For required fields, the "required" part of the validation pretty much always checks that the value is non-zero, though there are some minor exceptions like the replicas example above

[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