code-generator: create stable and more extensible cli interface for top-level scripts – "kube-gen"

[sttts]

The scripts https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/code-generator/generate-groups.sh and https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/code-generator/generate-internal-groups.sh were created to provide a standardized way of calling the generators for 90% of the CRD and UAS usa-cases. The command-line interface is simplistic, driven by the bash implementation rather than stability and extensibility in mind:

$ generate-groups.sh <generators> <output-package> <internal-apis-package> <extensiona-apis-package> <groups-versions> ...

I.e. the options are positional without flags syntax. Adding another option is impossible. Because #53449 should go into 1.8 as early as possible to give CRD users a tool to create especially deepcopy funcs easily, a proper Go implementation was out of reach because it is needs more changes, e.g. in Gengo (now merged). But mid-term we probably want to convert this to Go.

It was also suggested to turn k8s.io/code-generator into a Docker container to make it even easier to 3rdparties to generate code for Kubernetes style api types:

$ docker run -v $GOPATH:/go k8s.io/code-generator:1.8 generate-group github.com/foo/bar example:v1

Another line of thought is the question how and whether to use this also in Kubernetes itself instead of our pretty complex Makefile.generated_files mechanism.

[mml]

cc @pwittrock

I'm also curious about how we might implement this. Are we planning to make it a bazel target so that it can execute incrementally?

[pwittrock]

@mml just saw the comment. I had a similar idea to what you suggest, and think that would be really cool to build, as well as providing some lower level tools the bazel rules could leverage.

[pwittrock]

/assign @apelisse

[pwittrock]

/priority important-longterm

[pwittrock]

@sttts where should this go?

kubernetes/code-generator#17

[sttts]

where should this go?

Usually into the community repo or even just as google doc. I would not commit it into k/code-generator.

[pwittrock]

@ssts move to kubernetes/community#1315

[mml]

ITYM @sttts

…

On Wed, Nov 1, 2017 at 3:46 PM, Phillip Wittrock ***@***.***> wrote: @ssts <https://github.com/ssts> move to kubernetes/community#1315 <kubernetes/community#1315> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#53524 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAMK9vJAGQCeR5xMlaM_pNGtq3xgDy7ks5syPTFgaJpZM4PwLFD> .

[sttts]

@pwittrock is this work stalled?

[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

[sttts]

/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

[sttts]

This turned into kubebuilder.