kubebuilder should support generated clientset for types

[droot]

In v1 version, we stopped generating clientset because controller-runtime provides dynamic client which works with any type. However, having capability to generate clientset will help migrating existing projects to Kubebuilder easier.

[guanchao-yang]

@droot I can't agree more

[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

[DirectXMan12]

closing. It's doubtful that we'll add this -- it adds a lot of headaches, and runs counter to the design of KubeBuilder

[Cryptophobia]

This has been the most frustrating thing for me for the past 2 days. Inherited a tool that uses kubernetes CRDs that were obviously built with code-generator. Now I can't recreate the clients/informers/listers for the APIs to adhere to the new client-go versions...

Where in the design principles does it say that generating clients to access your APIs is against the design of Kubebuilder? Kubebuilder is a project generator but it's against the design principles to generate the clients to access your APIs and keep them steady across versions?

Prefer using go interfaces and libraries over relying on code generation

If you are designing to use steady and extendible interfaces, does it not mean you probably shouldn't be scared of code-generation...

So you generate a project and API, but then you are the mercy of using the Kubernetes clients at whatever version the clients care to use?

"Libraries Over Code Generation"

Literally people have been hacking around this to make kubebuilder and code-generator work together: https://www.fatalerrors.org/a/writing-crd-by-mixing-kubeuilder-and-code-generator.html

Maybe that should be a sign that your design principle are not very practical....

[thesuperzapper]

As was discussed in #1152, I think the recommended way for users to consume CRDs in Go apps is to use the client.Client from controller-runtime (even outside of Kubebuilder apps).

This then lets you simply import the generated CRD interface types from the Kubebuilder app, and you also get the benefit of being able to use cache.Cache if you want to avoid making requests to the Kubernetes API, at the expense of caching them in memory using a ListWatch.

That is, there is not really a need for explicitly generated client sets anymore.