Org: Repo creation request: kubernetes-sigs repo for moving out kubernetes/test-infra/kind

[BenTheElder]

New Repo, or migrate existing

New Repo (?) (Migrating a directory out of https://github.com/kubernetes/test-infra)

Requested name for new repository

kind would be ideal, it's the tool's name now, seems to not be in use elsewhere and is a good CLI / install path.

kind == Kubernetes IN Docker (see blow)

Which Organization should it reside

kubernetes-sigs -- this is a sig-testing project

Who should be provided access to this repository

e.g (at)example_user should have write access

• @bentheelder - I'd like at least write access (admin? owner? whatever is acceptable), I initially authored and currently maintain / actively develop this project
• @munnerz - should also have identical access to @bentheelder (munnerz is a co-approver and key contributor)
• @krzyzacy and @amwat - should at least be collaborators in the kubernetes-sigs org, they are test-infra maintainers and kind reviewers currently

Approvals

This is a SIG repository, I requested a vote by email and in the SIG weekly meeting for sig-testing:

• Three SIG-Testing leads voted in favor of this here: https://groups.google.com/forum/#!topic/kubernetes-sig-testing/DcvxFVaGqGo
• This was additionally discussed in the sig-testing meeting today with support. I'll add a link once the video is available. EDIT: here it is https://youtu.be/av3eFyyFryA

Additional context for request

Per the sig discussion, we've incubated this in test-infra under sig-testing, but we'd like to move it out (and in the future other parts of test-infra), and set up CI for it there without bogging down PRs to the test-infra config and other tools etc. We also need a way to version it back to kubetest which is in test-infra, so moving it out seems like the way to solve this.

[cblecker]

To be done:

• [x] Invite @BenTheElder @munnerz @krzyzacy and @amwat to @kubernetes-sigs
• [x] Create repo with template project
• [x] Update OWNERS
• [ ] Update sigs.yaml

[cblecker]

My only concern here is the extremely generic name.

@spiffxp @stevekuznetsov @fejta: Any comments on naming? Is this the best name for this tool/repo?

[BenTheElder]

I'm open to alternatives if someone has a better one, @munnerz suggested it and I've actually not found anyone using it. It makes for a great little command line / go install. kind create, kind build node --type=bazel etc.

[BenTheElder]

FWIW I also didn't think the name would be much of a problem being in @kubernetes-sigs rather than as a core project.

[spiffxp]

I'm fine with renaming it if we find that kind isn't the right name for it, but it's been discussed as kind thus far

[cblecker]

I'm asking you guys though. It seems generic to me, but it's ultimately a sig decision. First come first serve in k-sigs.

[BenTheElder]

Ok that makes sense to me. Do you mind if we keep the name for now? I think the sig is fine with it, we've discussed the project for a while now O(months) and not had any complaints about the name. I like it and haven't had any better ideas :-)

[stevekuznetsov]

kind seems an appropriate name for the project and we have not heard any objections in the SIG while development has been underway. I don't see any similar names in the k8s ecosystem with a couple cursory searches, so it doesn't seem like the name collides with anything. +1 from me

[cblecker]

SGTM. Will create tomorrow :)

[BenTheElder]

Thanks @cblecker 😄

[cblecker]

@BenTheElder is there a need for direct write access at this time (genuine question)? I've got you set up with top-level owners, and I've invited you all to the org. If we decide to leave it at OWNERS and find we need it later, we could add at that time.

[BenTheElder]

Uh possibly not? I was planning to port over history with filter branch which I've not used before.

[BenTheElder]

Let's see how far we can get for now, I'm a fan of our robot overlords :^) I hopefully don't actually need it. I may have to bug one of you at some point for more repo settings but we can sort that out when it happens :smile:

[cblecker]

@BenTheElder my thought is, let's dog food the "no direct write access" model if we can. You should be able to port over history with a PR. It would be great to see where the rough patches of that model are.

[BenTheElder]

https://github.com/kubernetes-sigs/kind/pull/1 not too bad, though README.md and OWNERS in the root make a lot of merge conflicts :sweat_smile:

• make a copy of the original repo somewhere
• DIR="kind" git filter-branch --prune-empty --subdirectory-filter "${DIR}" master
• rebase against the new upstream
• create a fork on github
• push to a branch in your fork
• PR to the new upstream

[cblecker]

last thing is getting sigs.yaml updated:
https://github.com/kubernetes/community/blob/bdf0c28d40ca04b8b5dd31c9946c1bf622195ef2/sigs.yaml#L1700-L1711

@spiffxp @stevekuznetsov @fejta: How would you like to handle that?

[stevekuznetsov]

Is everything a subproject if it has it's own repo?

[spiffxp]

Is everything a subproject if it has it's own repo?

It depends. There are subprojects like kubernetes-csi that span multiple repos, node-problem-detector that is a single repo root, and kubernetes-cloud-provider which spans multiple subdirs in a repo with no root

Here, I think it makes sense for kind to be its own subproject.

[spiffxp]

/close
and it's in sigs.yaml now

[k8s-ci-robot]

@spiffxp: Closing this issue.

In response to this:

/close
and it's in sigs.yaml now

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[BenTheElder]

Finally remembered to do this, sorry, video link is here: https://youtu.be/av3eFyyFryA
Updated the body above as well