Validate listType usage on struct fields

[lalitc375]

Validate listType usage on struct fields

Fixes : #554.

kube-openapi is updated to validate the usage of the // +listType marker. The tool will now generate an error if this marker is applied to any field that is not a slice or an array. This change ensures that the OpenAPI specifications for core Kubernetes types are generated with the same strictness as those for CRDs, preventing downstream tooling failures.

Problem:

Currently, kube-openapi allows the // +listType marker to be used on fields that are not lists or slices. This can result in the generation of an invalid OpenAPI schema. For example, a +listType=atomic marker was incorrectly applied to the metav1.Status.Details field, which is a struct, not a list type. This causes tools that consume the schema, such as controller-gen, to fail when generating Custom Resource Definitions (CRDs) that embed metav1.Status.

Solution:

This pull request introduces a validation check in kube-openapi to ensure that the +listType marker is only used on slice or array fields. If the marker is used on any other type of field, an error will be returned.

Unit tests have been added to verify the new validation logic, including a test case that is expected to fail when +listType is used on a string field.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: lalitc375
Once this PR has been reviewed and has the lgtm label, please assign jefftree for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-triage-robot]

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

This bot triages PRs 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 PR is closed

You can:

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

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

/lifecycle stale

[k8s-triage-robot]

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

This bot triages PRs 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 PR is closed

You can:

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

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

/lifecycle rotten