deepcopy-gen should have good support for existing APIs and not fail on difficult fields

[alexkreidler]

deepcopy-gen should be able to run on an existing API codebase with as minimal changes possible and without failing or throwing errors. This means that it should work on structs who also have

• interfaces
• functions
• maps

and other types. It should ignore these fields happily and without issues so we can run controller-gen object paths=./... on an existing codebase and it should generate as much as possible, but not fail and only output warnings for fields, etc which are not supported.

This would help achieve this high-level kubebuilder goal: kubernetes-sigs/kubebuilder#863

[DirectXMan12]

so most of these are somewhat intentional, in that their presence and the lack of a manual deepcopy method probably indicate a malformed Kubernetes API object. The issue is mainly that go types serve as the IDL for Kubernetes, but no all Go types and constructs "exist" in the IDL.

Skipping those fields might be fine for deepcopy (albeit pretty surprising), but what do we do for CRD generation?

[DirectXMan12]

/kind feature

[DirectXMan12]

(to be clear, I'm up for debate here, just laying out the existing thinking)

[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

[alexkreidler]

/remove-lifecycle stale

[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.