search

kubernetes-retired / contrib

[EOL] This is a place for various components in the Kubernetes ecosystem that aren't part of the Kubernetes core.
Apache License 2.0
2.46k stars 1.68k forks source link

Move code that should be maintained to dedicated repos #762

Closed bgrant0607 closed 5 years ago

bgrant0607 commented 8 years ago

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:

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

bprashanth commented 8 years ago

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?

spiffxp commented 8 years ago

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

bgrant0607 commented 8 years ago

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

davidopp commented 8 years ago

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 commented 8 years ago

@davidopp See the PR description.

davidopp commented 8 years ago

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 commented 8 years ago

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

bgrant0607 commented 8 years ago

@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 commented 8 years ago

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

spxtr commented 8 years ago

mungegithub could go into test-infra.

bprashanth commented 8 years ago

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 commented 8 years ago

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

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.

ingvagabund commented 8 years ago

Ansible will go under kubernetes/kube-deploy repository (sooner or later).

bgrant0607 commented 8 years ago

As mentioned by @thockin in https://github.com/kubernetes/contrib/issues/1389#issuecomment-235161997 and in comments above, we should move mungegithub to another repo. I'm currently thinking github-tools. We also need to move the doc munger, as mentioned in https://github.com/kubernetes/kubernetes/issues/29314. Other github-related tools could go into that repo, also.

thockin commented 8 years ago

+1, having a distinct repo would further the goal of being repo-agnostic and generic.

On Mon, Jul 25, 2016 at 11:14 PM, Brian Grant notifications@github.com wrote:

As mentioned by @thockin https://github.com/thockin in #1389 (comment) https://github.com/kubernetes/contrib/issues/1389#issuecomment-235161997 and in comments above, we should move mungegithub to another repo. I'm currently thinking github-tools. We also need to move the doc munger, as mentioned in kubernetes/kubernetes#29314 https://github.com/kubernetes/kubernetes/issues/29314. Other github-related tools could go into that repo, also.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kubernetes/contrib/issues/762#issuecomment-235172618, or mute the thread https://github.com/notifications/unsubscribe-auth/AFVgVPOAoMJ4bVMz016PQzaFS8CewKFRks5qZaXIgaJpZM4IFmN5 .

bgrant0607 commented 8 years ago

Stab at suggesting where each thing should go. Will gradually fill these in. Suggestions welcome.

bprashanth commented 8 years ago

Filed https://github.com/kubernetes/contrib/issues/1441 for ingress

rmmh commented 8 years ago

Mungegithub should be in its own repo.

Travis CI should work well for almost all of these repos, since they should have small, fast test suites. This also means the submit queue flow shouldn't be necessary-- just merge when the CI status is green.

bgrant0607 commented 8 years ago

@rmmh If tests are fast, then submit queue will be fast.

rmmh commented 8 years ago

OK, we can make the submit-queue trigger a travis build to test the merge commit then. Travis is a much better experience for everyone involved.

thockin commented 8 years ago

dnsmasq should probably move into a kube-dns repo, along with the kube-dns code.

On Tue, Jul 26, 2016 at 10:01 AM, Brian Grant notifications@github.com wrote:

Stab at suggesting where each thing should go. Will gradually fill these in. Suggestions welcome.

  • 404-server: For testing Ingress. Move to ingress repo or test-infra.
  • addon-resizer: Move to kube-deploy.
  • ansible: Move to kube-deploy or merge with kargo and delete.
  • cluster-autoscaler: Move to cluster-autoscaler repo.
  • cni-plugins: Move to cni-plugins repo.
  • compare: Move to test-infra repo.
  • continuousdelivery: Move to kubernetes/examples (which should be moved to a new repo eventually).
  • diurnal: Not maintained. Delete.
  • dnsmasq:
  • docker-micro-benchmark:
  • election:
  • exec-healthz:
  • for-demos:
  • git-sync:
  • hack:
  • images:
  • ingress: Move to ingress repo.
  • init:
  • keepalived-vip
  • kubeform:
  • kubelet-to-gcm:
  • logging
  • micro-demos
  • mungegithub
  • netperf-tester
  • perfdash:
  • pets:
  • podex: Obsolete. Delete.
  • prometheus: Move to kubernetes/examples.
  • recipes
  • release-notes: Move to release repo.
  • rescheduler: Move to rescheduler repo.
  • scale-demo
  • service-loadbalancer
  • test-utils: Move to test-infra repo.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kubernetes/contrib/issues/762#issuecomment-235334556, or mute the thread https://github.com/notifications/unsubscribe-auth/AFVgVAazjiaQ9miBm8j94HHS6cY-7gVbks5qZj1_gaJpZM4IFmN5 .

spxtr commented 8 years ago

I agree that travis should be sufficient for most repos. However, travis can be a bit of a pain when you have multiple languages, or when you want to do long or continuous testing. Travis also limits to 5 concurrent builds per org, so that's not great. I'm working on something better right now but it won't be ready right away.

I would really rather not run the submit queue/mungers against every repo. Just click the big green merge button when it's passed CI.

bgrant0607 commented 8 years ago

Created pr-bot repo for mungegithub.

kokhang commented 8 years ago

I have this PR https://github.com/kubernetes/contrib/pull/1343, which adds a new project in contrib. In light of this discussion, where should i make it go? I would like to make this project available and open for the community.

bgrant0607 commented 8 years ago

@kokhang I suggest your own github account.

kokhang commented 8 years ago

@bgrant0607 If i have it in my own github account, how would the kubernetes community know about it so that it can be used and contributed? Would that be done through links and docs?

Also, since this relates to service-loadbalancer, do we know where this project will go?

Thanks,

bgrant0607 commented 8 years ago

@kokhang Good question for https://kubernetes.slack.com/messages/community-sites/

Q-Lee commented 8 years ago

@spxtr clarification needed: i18n or programming languages?

Q-Lee commented 8 years ago

@bgrant0607 @bprashanth I'm confused now - where will new service loadbalancers go? Imo, a netscaler implementation is a great addition for on-premise k8s deployments.

bprashanth commented 8 years ago

@kokhang I'd rather hold off checking in a uber serviceloadbalancer implementation (https://github.com/kubernetes/contrib/pull/1343). Suggest keeping it in a local repo for now.

We will at some point in the not too distant future need to figure out what we do with serviceloadbalancer (https://github.com/kubernetes/contrib/tree/master/service-loadbalancer), because we're about to decommission contrib/ entirely. I will probably take some sort of community poll to figure out if it's worth maintaining, depending on who's using it for what. If https://github.com/kubernetes/contrib/pull/1343 is feature compatible, and we decide that we do need a serviceloadbalancer implementation, we should put the mult-backend version through the incubator (https://docs.google.com/document/d/1ugAd9Zj-jW3YHdrNVdktmvDMEWtChPqyGHfkwWdQ3zo/edit#).

where will new service loadbalancers go?

@Q-Lee If we go the incubator route, they will become backends for https://github.com/kubernetes/contrib/pull/1343

Imo, a netscaler implementation is a great addition for on-premise k8s deployments.

https://github.com/kubernetes/contrib/issues/1440 is an Ingress controller for Netscale. Probably the best place to keep it is in an official Netscaler repo, like nginx does: https://github.com/nginxinc/kubernetes-ingress (we also have an nginx ingress but they have different goals, ours tries to maintain cross platform purity, while theirs tries to surface nginx plus features).

thockin commented 8 years ago

This is a two-edged sword, of course. If users who wan to assemble a k8s cluster have to pull pieces from all over the internet to do it, the perception will be that this is a piecemeal, cobbled-together system. we have to find a balance.

On Thu, Aug 11, 2016 at 3:19 PM, Prashanth B notifications@github.com wrote:

@kokhang https://github.com/kokhang I'd rather hold off checking in a uber serviceloadbalancer implementation (#1343 https://github.com/kubernetes/contrib/pull/1343). Suggest keeping it in a local repo for now.

We will at some point in the not too distant future need to figure out what we do with serviceloadbalancer (https://github.com/ kubernetes/contrib/tree/master/service-loadbalancer), because we're about to decommission contrib/ entirely. I will probably take some sort of community poll to figure out if it's worth maintaining, depending on who's using it for what. If #1343 https://github.com/kubernetes/contrib/pull/1343 is feature compatible, and we decide that we do need a serviceloadbalancer implementation, we should put the mult-backend version through the incubator ( https://docs.google.com/document/d/1ugAd9Zj-jW3YHdrNVdktmvDMEWtChPqyGHfkwW dQ3zo/edit#).

where will new service loadbalancers go?

@Q-Lee https://github.com/Q-Lee If we go the incubator route, they will become backends for #1343 https://github.com/kubernetes/contrib/pull/1343

Imo, a netscaler implementation is a great addition for on-premise k8s deployments.

1440 https://github.com/kubernetes/contrib/pull/1440 is an Ingress

controller for Netscale. Probably the best place to keep it is in an official Netscaler repo, like nginx does: https://github.com/nginxinc/ kubernetes-ingress (we also have an nginx ingress but they have different goals, ours tries to maintain cross platform purity, while theirs tries to surface nginx plus features).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kubernetes/contrib/issues/762#issuecomment-239311059, or mute the thread https://github.com/notifications/unsubscribe-auth/AFVgVAzKUsrjymTj8NzECY1r4hW23M1Fks5qe6AFgaJpZM4IFmN5 .

kokhang commented 8 years ago

@bprashanth I am all for trying to get the multi-backend service LB (#1343) in kubernetes incubator. Having it in my own repo would be hard for the community to know about and contribute to it.

Did this incubator process result as part of the elimination of /contrib?

vipulsabhaya commented 8 years ago

@kokhang @bprashanth Just to be clear, #1343 is not a drop-in replacement (yet) of service-loadbalancer. We would need to add L7 ingress support to it.

thockin commented 8 years ago

I don't MIND adding new repos under kubernetes, if we think that they will lead towards generally useful, generic, components. I have not had a chance to digest this repo in particular, but maybe you should START with it in your own space, and get it to a place where it's really useful to a few folks and then talk about incubating it?

There's a certain gravitas that projects under kubernetes/* should have (I said SHOULD - not all do)

On Mon, Aug 15, 2016 at 2:55 PM, Vipul Sabhaya notifications@github.com wrote:

@kokhang https://github.com/kokhang @bprashanth https://github.com/bprashanth Just to be clear, #1343 https://github.com/kubernetes/contrib/pull/1343 is not a drop-in replacement (yet) of service-loadbalancer. We would need to add L7 ingress support to it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kubernetes/contrib/issues/762#issuecomment-239941581, or mute the thread https://github.com/notifications/unsubscribe-auth/AFVgVMbjX3y25zkdKVe4M1WcOT2y0uaKks5qgOBAgaJpZM4IFmN5 .

bgrant0607 commented 8 years ago

git-sync has its own repo: https://github.com/kubernetes/git-sync

thockin commented 8 years ago

git-sync is an example of a really self-contained thing that doesn't even really have to live in kubernetes, except we don't have a better place to stick it (and we want to rely on it, I guess). Many repos will not be sol self-contained, but that's what we should strive for.

On Tue, Aug 23, 2016 at 4:39 PM, Brian Grant notifications@github.com wrote:

git-sync has its own repo: https://github.com/kubernetes/git-sync

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kubernetes/contrib/issues/762#issuecomment-241914914, or mute the thread https://github.com/notifications/unsubscribe-auth/AFVgVI59i0vZ0UYthwtVemjiRBcCed71ks5qi4SrgaJpZM4IFmN5 .

porridge commented 8 years ago

@thockin when creating new repos, do you think there should be a naming convention? For example in case of https://github.com/kubernetes/contrib/issues/1441, should its new home be github.com/kubernetes/controller-ingress or just plain github.com/kubernetes/ingress?

Something worth thinking about before there are 10 pages of repos under kubernetes...

thockin commented 8 years ago

We could also use multiple orgs, since GitHub has no other nesting.

Something like kubernetes-sidecars/git-sync and kubernetes-addons/ingress

I don't know if we need to impose naming conventions yet, or if we do it is not clear what they should be...

On Fri, Oct 28, 2016 at 9:43 AM, Marcin Owsiany notifications@github.com wrote:

@thockin https://github.com/thockin when creating new repos, do you think there should be a naming convention? For example in case of #1441 https://github.com/kubernetes/contrib/issues/1441, should its new home be github.com/kubernetes/controller-ingress or just plain github.com/kubernetes/ingress?

Something worth thinking about before there are 10 pages of repos under kubernetes...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kubernetes/contrib/issues/762#issuecomment-256857343, or mute the thread https://github.com/notifications/unsubscribe-auth/AFVgVIkb8UbtZR0trouK5grePs60NGsFks5q4aesgaJpZM4IFmN5 .

fejta-bot commented 6 years ago

Issues go stale after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

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

spiffxp commented 6 years ago

/lifecycle frozen The only way this repo ever goes away is if we find a home for or explicitly deprecate the code within