Move code that should be maintained to dedicated repos

[bgrant0607]

contrib isn't monitored adequately for maintained code. Issues aren't triaged. PRs aren't reviewed. We need to fix those problems, but it's not a good idea to mix maintained and unmaintained code.

Examples:

• addon-resizer
• ingress and service-loadbalancer
• test infra/utils and mungeithub
• do we still need release-notes?
• ansible?

cc @bprashanth @eparis @david-mcmahon @mikedanese @ixdy @Q-Lee

[bprashanth]

Yeah I've brought this up before.
I think we decided (at the time) that we don't really get much from splitting Ingress out into another repo.

Fwiw both serviceloadbalancer and ingress have e2es (https://github.com/kubernetes/kubernetes/blob/master/test/e2e/ingress.go) in the main repo that consume released images from: https://github.com/kubernetes/contrib/releases. Unittests will run as part of contrib pre-checking github hooks. I usually include a line in the release notes when I bump up the image in: https://github.com/kubernetes/kubernetes/blob/master/cluster/addons/cluster-loadbalancing/glbc/glbc-controller.yaml#L21

It's a hand wavy process that I'd like to improve.

The meta issue is: How do we manage cluster addons?

• Where are they run?
  • If they're on the node, then we need to be really careful about increasing request limits
  • If they're on the master, we need to allow users to swap them out (eg: gce l7 for nginx)
• Where do they live?
  • kube-dns is checked into main
  • heaptster has it's own repo but not sure about e2es
  • Ingress is described above
  • cadvisor runs as part of kubelet but still has its own repo/release.
• Are they all shipped by default, with every cluster?
  • Increases resources required for smallest cluster
  • If we don't, Ux is worse, docs harder to write (eg: start an Ingress controller, then create this)
• How are they tested?
  • Ingress would benefit from a builder available to the community
  • Running e2es from contrib/-HEAD would also be a big simplification
  • But if each of these gets a seperate e2e-builder how do these block a release?

[spiffxp]

/cc @kubernetes/sig-testing we've talked about moving test infra out before

[bgrant0607]

I would like to nuke contrib. It's no longer needed by the community.

[davidopp]

I would like to nuke contrib. It's no longer needed by the community.

Can you clarify? What would we do with the stuff that's currently in kubernetes/contrib?

[bgrant0607]

@davidopp See the PR description.

[davidopp]

Ah OK, so what you're saying is "once we move everything from contrib out of contrib, contrib will no longer be needed"? I can't really disagree with that. :)

[eparis]

Where does mungegithub go? I don't care mind you....

[bgrant0607]

@eparis mungegithub would go into something like "productivity-tools". Some repo with a clear set of responsible owners, who would review its PRs, triage its issues, build and push updates to the tool(s), etc.

[bgrant0607]

Note that we might just delete some things (e.g., podex, which is totally broken at this point).

[spxtr]

mungegithub could go into test-infra.

[bprashanth]

contrib isn't monitored adequately for maintained code. Issues aren't triaged. PRs aren't reviewed. We need to fix those problems, but it's not a good idea to mix maintained and unmaintained code.

If there're projects suffering from this in subdirectories of contrib/, I feel like they'll suffer from it in another repo too.

I also think we should be clear about the bar for a new project under kubernetes/ repo.

I want a place to incubate ideas without putting serious time and effort into making it production ready. For example, the keepalived project: https://github.com/kubernetes/contrib/tree/master/keepalived-vip is a useful prototype of an ipvs replacement of kube-proxy. Splitting that out into kubernetes/keepalived-vip doesn't help, it'll still be only a prototype. Keeping it under bprashanth/keepalived-vip doesn't either, because I want people to use it/contribute etc.

[bgrant0607]

@bprashanth Github is optimized for small, single-purpose repos. Separate repos have several benefits.

• Clear ownership, even without additional tooling
• Independent management of admin and write access
• Easy to set up independent CI
• Small and focused enough to make notification subscription feasible
• More easily independently forked/cloned
• Can't accrue spurious dependencies

Bar should be something potentially reasonably useful that someone on the project is willing to maintain, at least so long as it exists. If we're not going to maintain it (at least respond to PRs and issues), it belongs elsewhere.