add clientset/lister/informer generation #1194
Conversation
|
This change is |
|
Why do we need such a generation? Will you use it to build some upper-level projects? |
Actually I want to preserve/track katib custom resources (experiments/suggestions/trials) with internal agent which requires listers and informers of CRDs. I think, as our internal agent, typed clients/listers/informers are usually essential, in order to interact with other kubernetes-native systems. |
|
/lgtm We are using k8s-sigs/controller-runtime/pkg/client to do such things. But I think this feature is necessary. |
|
@gaocegege Yes, many early-built controllers (such as tf-operator) are based on client-go instead of kube-builder. Thanks for review! |
| github.com/kubeflow/katib/pkg/client/controller \ | ||
| github.com/kubeflow/katib/pkg/apis/controller \ | ||
| "common:v1alpha3 experiments:v1alpha3 suggestions:v1alpha3 trials:v1alpha3" \ | ||
| --go-header-file ${PROJECT_ROOT}/hack/boilerplate.go.txt |
There was a problem hiding this comment.
Do we need boilerplate.go.txt file in /hack folder for header?
There was a problem hiding this comment.
@andreyvelich Maybe we can change it to kubeflow specialized header ?
There was a problem hiding this comment.
Should it be specific to Kubeflow licence, like here: https://github.com/kubeflow/katib/blob/master/hack/verify-gofmt.sh#L2-L14 ?
|
Instead of all files, why don't we just keep the generator files in the upstream? If someone needs it, it can run the generator files to generate all. Since Kubebuilder won't use this at all, I feel that we should avoid it in the upstream |
I think it does not work since we cannot use vendor to install these packages. Then the users have to maintain a fork of katib. I think we should keep all the client and informer in the upstream, or just do not support it. |
|
|
||
| PROJECT_ROOT=${GOPATH}/src/github.com/kubeflow/katib | ||
| CODEGEN_PKG=${PROJECT_ROOT}/vendor/k8s.io/code-generator | ||
| VERSION_LIST=(v1alpha3 v1beta1) | ||
| SWAGGER_VERSION="0.1" |
There was a problem hiding this comment.
For each Katib version Swagger Version will be v0.1, is that fine?
There was a problem hiding this comment.
@andreyvelich I've refined the schema of swagger version, which became ${katib_version}-{swagger_sub_version}. So, with swagger version, we can figure out katib version who generated it.
|
/retest |
|
@andreyvelich @johnugeorge PTAL /lgtm |
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: johnugeorge The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
* adapt v1beta1 * add resources for v1alpha3 * fix * refine update-codegen script * add katib apiVersion as prefix of swagger version
This PR is to refine kubernetes clients generation for katib. The major contribution is generating codes of clientset/lister/informer via
k8s.io/code-generator/generate-groups.sh.In order to run
generate-groups.shproperly, projectk8s.io/code-generatorandk8s.io/gengoneed to be unpruned.Could you help to review this PR? @andreyvelich @gaocegege @johnugeorge