KEP 4402: Go workspaces for k/k (first draft)

[thockin]

• One-line PR description: First draft
• Issue link: Go workspaces for k/k #4402

The main Kubernetes git repo (github.com/kubernetes/kubernetes, colloquially
called "k/k") is the empdiment of evolution. When it was created, the only
way to build Go applications was GOPATH. Over time we built tooling which
understood GOPATH, and it leaked into many parts of our build, test, and
release systems. Then Go added modules, in part because GOPATH was unpleasant
and had a tendency to leak into tools. We adopted modules, but we also added
the idea of "staging" repositories - a way to eat our cake and have, too. We
get the benefits of a monorepo (atomic commits, fast iteration across repos)
and then publish those to standalone repos for downstream consumption. To make
this work with modules, we abused GOPATH even harder and wrote even more tools.

The Go project saw what we (and others) were doing and did not like it. So
they created workspaces. They
basically created a solution that is purpose-built for us.

This KEP proposes that we adopt Go workspaces and bring our tooling up to
modern standards. In fact, the author started this work in 2021 or 2022,
discovering issues along the way that the Go team has worked to resolve.

This is not a user-facing change. No k8s cluster-user or cluster-admin should
know or care that this happened. On the surface, it seems like something that
should not warrant a KEP, but:
a) KEPs are how we communicate big changes;
b) This is a big change;
c) There's some ecosystem impact to developers

[pohly]

Let's do this... 👍 from me.

Some small nits on the text itself.

[thockin]

Most comments addressed, added details about sequencing PRs.

TBD:

1. Break k8s.io/code-generator for legacy users (tag it and tll them to pin), vs. code-generator/v2 (in staging), vs. fork legacy-code-generator in staging.
2. Change kube-openapi in place or kube-openapi/v2

[pohly]

Break k8s.io/code-generator for legacy users (tag it and tll them to pin), vs. code-generator/v2 (in staging), vs. fork legacy-code-generator in staging.

I doubt that we have the necessary tooling to publish a k8s.io/code-generator/v2 from staging/src/k8s.io/code-generator: the next tagged release will be v0.30.0, not some v2.0.0.

Forking it as legacy-code-generator would work, but not help consumers who are using k8s.io/code-generator without pinning to a version.

We could fork it as code-generator-v2 and leave the old staging/src/k8s.io/code-generator more or less unchanged from now on (minimal maintenance forever) or declare it as deprecated and remove it at some point in the future. We can also do this in stages:

• in 1.30, fork it internally as staging/src/k8s.io/code-generator-v2 without publishing it as k8s.io/code-generator-v2
• in 1.31, publish it and declare k8s.io/code-generator as deprecated
• at some point later, remove staging/src/k8s.io/code-generator

I don't know how disruptive the changes will be. If we want to be nice to the eco system, then playing it safely with fork/deprecate might be better. If we want to be done quickly (= "rip off the bandage"), then we don't fork and just warn consumers about the change.

Change kube-openapi in place or kube-openapi/v2

No strong opinion here. Just beware that if we start versioning it, then someone has to remember to do releases from now on because "latest" would refer to the latest release, not the master branch as it does now.

[thockin]

I doubt that we have the necessary tooling to publish a k8s.io/code-generator/v2

Agree

[thockin]

@sttts @soltysh @deads2k - can you bring more eyes to this?

[MikeSpreitzer]

@MikeSpreitzer

[thockin]

With KEP freeze coming, I would love to have the KEP approved, so that the implementation has a chance of landing in .30

@jpbetz and @liggitt are listed as approvers. I'd appreciate even an initial ACK from @soltysh if possible?

@jpbetz I took the liberty of making you PRR for this one, is it a problem if you are also approver?

[jpbetz]

@jpbetz I took the liberty of making you PRR for this one, is it a problem if you are also approver?

Not a problem! I've seen this being done elsewhere.

[jpbetz]

/approve
/lgtm

[liggitt]

/lgtm
/approve

[liggitt]

/lgtm cancel

the v2-experiment file is in the wrong folder. move that, then lgtm

[thockin]

File moved

[liggitt]

/lgtm
/approve
/assign @dims

[dims]

/lgtm
/approve
/hold ... please remove hold when ready (need more reviewers?)

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dims, jpbetz, liggitt, thockin

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:

• keps/prod-readiness/OWNERS [jpbetz]
• keps/sig-architecture/OWNERS [dims]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[thockin]

If it's OK, I'd like merge and iterate. If @soltysh or someone else can weigh in, it would be awesome, but I have pretty high confidence this is the right direction and any niggles will emerge in the PR.

[liggitt]

need this updated to implementable by next Thursday

[thockin]

sigh, I missed it.

…

On Thu, Feb 1, 2024 at 3:01 PM Jordan Liggitt ***@***.***> wrote: @liggitt commented on this pull request. ________________________________ In keps/sig-architecture/4402-go-workspaces/kep.yaml: > @@ -0,0 +1,27 @@ +title: Go workspaces for k/k +kep-number: 4402 +authors: + - ***@***.***" +owning-sig: sig-architecture +participating-sigs: + - sig-release + - sig-api-machinery +status: provisional need this updated to implementable by next Thursday — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[soltysh]

If it's OK, I'd like merge and iterate. If @soltysh or someone else can weigh in, it would be awesome, but I have pretty high confidence this is the right direction and any niggles will emerge in the PR.

Sorry was out last week, but I don't have any objections. I'll keep on looking through the appropriate PRs.

[thockin]

You'll have time to object as PRs queue up. The first one is for gengo, which probably doesn't affect you. Once the k/k PR(s) stabilize, you will have something proper to try.

Now that 1.22 is released, I will rebase the k/k PR and it should mostly pass.

Once KEPs freeze, I will push more to get PRs approved to keep the pipeline moving.