Tracking: Enable Kube-API-Linter rules

This is issue is to help track the various Kube API Linter rules that have been implemented, and whether they are ready to be integrated into K/K. I've assessed each rule, including those in open issues that I think will be implemented and divided into categories

When taking on an issue below

Start by commenting on this issue to say that you're going to take a particular issue. We want to make sure we don't duplicate work with multiple PRs for the same work.

Checkout the latest master branch and enable your chosen rule (or remove part of an exclusion if that's appropriate) in the hack/kube-api-linter/kube-api-linter.yaml file. Run hack/update-golangci-lint-config.sh to update the config and then hack/verify-golangci-lint.sh staging/src/k8s.io/api to run the linter. This should only report newly found issues for your linter.

Assess existing issues, should they be excepted, or can they be fixed in a non-breaking way. If you are unsure, post on this thread for help on making that decision. In general, most issues reported by the linter should not be fixed by changing the existing Go types.

For linters with hundreds of violationsTake a look at how I've handled optionalorrequired, https://github.com/kubernetes/kubernetes/pull/134675. In this case we've built up a table of how many issues exist per API group and have decided to tackle each API group 1 by 1. We don't expect this to be the norm, but in some cases we do genuinely have hundreds of issues to trawl through to determine whether or not they can be fixed and how they can be fixed.

Done

Rule Name	Is Implemented	Is Enabled on K/K	Should be enabled on K/K	Is ready to be enabled on K/K	Assignee	Notes
conditions	Y	Y	Y	Y	@JoelSpeed
ssatags	Y	Y	Y	Y	@JoelSpeed
conflictingmarkers	Y	N	Y	Y	@yongruilin	Being added in https://github.com/kubernetes/kubernetes/pull/134229 for default vs required and optional vs required conflicts
duplicatemarkers	Y	N	Y	Y	@kannon92	Prevent identical markers from being present on types and fields See #134734
notimestamp	Y	N	Y	Y	@shwetha-s-poojary	Should not have new fields with timestamp in the name. See #134966
nomaps	Y	N	Y	Y	@MatteoFari	Prevents non - map[string]string type maps. See #134852
integers	Y	N	Y	Y	@JoelSpeed	Checks for usage of non-int32/int64 types ints and prevents it. Will need exceptions for existing issues. See https://github.com/kubernetes/kubernetes/pull/134680
nonullable	Y	N	Y	Y	@JoelSpeed	Prevents the use of the nullable marker on types. See https://github.com/kubernetes/kubernetes/pull/134681
nodurations	Y	N	Y	Y	@ShaanveerS	No longer recommended to use durations, exceptions needed for all existing cases. See #134867

In Progress

Rule Name	Is Implemented	Is Enabled on K/K	Should be enabled on K/K	Is ready to be enabled on K/K	Assignee	Notes
optionalorrequired	Y	N	Y	Y	@JoelSpeed (help wanted)	All fields should be tagged either optional or required. Many exceptions (~900) to work through. Probably want to break this down per API group. See https://github.com/kubernetes/kubernetes/issues/134671#issuecomment-3415486017 for details.
jsontags	Y	N	Y	Y	@MatteoFari	Checks all json tags are camelCase (regex can be customised) - See #134830
nophase	Y	N	Y	Y	@Shubhamag12	Should not have new phase fields. See #134842
commentstart	Y	N	Y	Y	@liyuerich	All comments should start with json tag. Lots of existing issues to ignore/fix
optionalfields	Y	N	Y	Y	@itzPranshul	Checks serialization of optional marked fields. All should be pointers and have omitempty in k/k

Ready to be assigned

Rule Name	Is Implemented	Is Enabled on K/K	Should be enabled on K/K	Is ready to be enabled on K/K	Assignee	Notes

Needs KAL work

Rule Name	Is Implemented	Is Enabled on K/K	Should be enabled on K/K	Is ready to be enabled on K/K	Assignee	Notes
maxlength	Y	N	Y	N		Checks strings for MaxLength, arrays for MaxItems, reports when missing. Doesn’t have knowledge of DV markers yet.
requiredfields	Y	N	Y	N		Checks serialization of required marked fields. Needs to be able to identify if the zero value is valid or not. Needs a handful of DV markers implementing to understand this.
uniquemarkers	Y	N	Y	N		Checks for unique values for markers, eg only allow one maximum value to be specified. Needs to understand lots of DV markers before it is helpful. PR for 1.35 DV markers
dependenttags	N	N	Y	N		Needs to be implemented in KAL tracker. Would be used to enforce relationships like unionMember fields must be optional
markerscope	N	N	Y	N		Needs to be implemented in KAL tracker. Would ensure that tags are applied to the right scope, e.g. field vs object vs array vs map. Will need knowledge of DV markers
preferredmarkers	N	N	Y	N		Needs to be implemented in KAL tracker. Will be used to ensure usage of newer versions of markers, e.g. when we have taught everything about +k8s:optional, this will move usage of +optional to the new marker and prevent new usage of the old marker
defaultorrequired	N	N	Y	N		Needs to be implemented in KAL tracker. Prevent usage of default tags with required fields (configuration of conflictingmarkers already covers this).
minlength	N	N	Y	N		WIP PR in KAL. Will then need DV marker knowledge. Requires authors to think about the minimum length of strings/arrays/maps/structs.
references	N	N	Y	N		Needs to be implemented in KAL tracker. Ensure Ref/Refs is preferred over Reference/References. Is a naming convention configuration.
defaults	N	N	Y	N		Needs to be implemented in KAL tracker. Ensure we only use the default marker and no variation of it, both built-ins and CRDs share the same marker.
numericbounds	N	N	Y	N		Needs to be implemented in KAL tracker. Ensure all integer values set a minimum and maximum bound
enums	N	N	Y	N		Needs to be implemented in KAL tracker. Ensure enums are PascalCase, apart from specific exceptions that can be configured where this rule doesn't make sense.

Open questions

Rule Name	Is Implemented	Is Enabled on K/K	Should be enabled on K/K	Is ready to be enabled on K/K	Assignee	Notes
nobools	Y	N	Y?	Y		Would prevent all bools, or exceptions. This would make people think twice, but need to check with sig-arch if they are happy with people adding exceptions over time if they find a valid use case
nofloats	Y	N	Y?	Y		As with nobools, but for floats, same open question
typeandobjectmeta	N	N	Y?	N		Ensure correct tags on typemeta and objectmeta in root object struct definition. Need to work out what the correct tags are (omitzero? optionality?)
arrayofstruct	N	N	Y?	N		KAL tracker. All arrays of objects should have at least one required field in them. TBD with sig-arch do we agree. Has caused bugs in the past with networking types
markertypos	N	N	Y?	N		KAL tracker. Would detect typos in markers. Need to work out how to detect typos first.
discriminatedunions	N	N	Y?	N		KAL tracker. Ensure union shapes are correct and for CRDs enforce CEL validation of unions. DV will need to have implemented union support before this can be useful

Needs use case

Rule Name	Is Implemented	Is Enabled on K/K	Should be enabled on K/K	Is ready to be enabled on K/K	Assignee	Notes
forbiddenmarkers	Y	N	N	Y		Could be enabled, but so far we don’t know of any markers that need to be forbidden on k/k explicitly
namingconventions	Y	N	N	Y		We don’t have any specific configuration for this yet that isn’t already handled in other places

Not applicable to K/K

Rule Name	Is Implemented	Is Enabled on K/K	Should be enabled on K/K	Is ready to be enabled on K/K	Assignee	Notes
statusoptional	Y	N	N	Y		Checks that all first level children of status are optional. Is true of most APIs but not a convention.
statussubresource	Y	N	N	Y		Not applicable to built-in types
nameformats	N	N	N	N		Not applicable to built-in types
pointeroptional	N	N	N?	N		We closed this as a won't do.