Incorrect crd properties generated for structs defined in k8s/api

[FillZpp]

Hi folks,

we define CRD with fields defined in k8s.io/api, such as:

import (
    v1 "k8s.io/api/core/v1"
)

type CloneSetSpec struct {
    // ...
    Template v1.PodTemplateSpec `json:"template"`
    // ...
    VolumeClaimTemplates []v1.PersistentVolumeClaim `json:"volumeClaimTemplates,omitempty"`
}

For this kind:

• With controller-tools v0.1.x, the CRD yaml is generated like this.

  This is ok, all structs defined in k8s.io/api are all generated without properties. It is because controller-gen in this version will ignore for k8s.io/api https://github.com/kubernetes-sigs/controller-tools/blob/release-0.1/pkg/internal/codegen/parse/crd.go#L457

• But with controller-tools higher than v0.2.x, the CRD yaml is generated like this.

  It generates properties for structs defined in k8s.io/api, which not only makes the CRD yaml much bigger, but also causes incorrect validation.

Problems we have found:

1. For VolumeClaimTemplates []v1.PersistentVolumeClaim, it requires user to define dataSource in v1.PersistentVolumeClaim, which should be optional. (Issue)
2. For Template v1.PodTemplateSpec, it will return The CloneSet "demo" is invalid: type: Required value when we define downwardAPI in template.spec.volumes.

So, could we skip to generate properties for structs defined in k8s.io/api, just like the v0.1.x did?

[FillZpp]

/kind bug

[cbandy]

To me, the validation of core types is a feature rather than a bug. Without it, I would have to implement a validating webhook to verify core types, yes? There are some limitations (declarative defaults, #444) and possibly bugs, but those should be fixed upstream on the core types rather than here.

I see that PersistentVolumeClaimSpec.DataSource has always been tagged +optional, so perhaps that is a bug in this project.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.