Org: Request for new SIG-CLI kubernetes-sigs repo - cli-experimental

[pwittrock]

New Repo, Staging Repo, or migrate existing

New Repo

Requested name for new repository

cli-experimental

Which Organization should it reside

kubernetes-sigs

If not a staging repo, who should have admin access

@pwittrock
@seans3
@soltysh

If not a staging repo, who should have write access

@monopole
@liggitt
@Liujingfang1

If not a staging repo, who should be listed as approvers in OWNERS

@pwittrock
@seans3
@soltysh

If not a staging repo, who should be listed in SECURITY_CONTACTS

@pwittrock
@seans3
@soltysh

What should the repo description be

Experimental Kubectl libraries and commands.

• kubectl 2.0
• create / set 2.0

What SIG and subproject does this fall under in sigs.yaml

This is a new subproject for sig-cli called cli-experimental

Approvals

• https://groups.google.com/forum/#!topic/kubernetes-sig-cli/FMl1A8RkK6w
• https://github.com/kubernetes/kubectl/issues/622

[bgrant0607]

This is completely reasonable and in the scope of SIG CLI.

[smarterclayton]

I would prefer we don't use cutesy names for an experimental thing, but prefer cli-experimental or something.

kraken is a Docker proxy published by uber that can be used with kubernetes, so we're going to run into names.

Also, kustomize would have been less contentious if it had just been a simple command name like apply-unit, so giving "pretty" names creates a sense of something abnormal vs something that is just normal bounds of a sig.

[pwittrock]

I would prefer we don't use cutesy names for an experimental thing, but prefer cli-experimental or something.

SGTM. Do you have a preference on the binary name?

Edit: Updated

[smarterclayton]

Is it purely for experimentation? kubectl-next or kubectl-prototype would give that sense. Or just kcli-exp or kcli-new or something.

[pwittrock]

cc @soltysh
cc @juanvallejo
cc @JiangtianLi

[pwittrock]

Is it purely for experimentation?

I think of it more as an experiment. However if it is a successful experiment we need to decide how to proceed - e.g. do we upstream the functionality into kubectl, deprecate it from kubectl, or keep it in both places.

~How about kr for Kubernetes Resources.~

Edited: Can probably figure out naming of the binary as a follow up. It doesn't need to match the name of the repo.

[nikhita]

@pwittrock to confirm, do you want to go forward with the name cli-experimental then?

[pwittrock]

@nikhita Yes, lets move forward with cli-experimental. We can always graduate things out of cli-experimental into new subprojects as they mature.

[nikhita]

/assign

[nikhita]

Repo created https://github.com/kubernetes-sigs/cli-experimental :tada:

Created:

• https://github.com/kubernetes/org/pull/668: to add GitHub teams for the repo
• https://github.com/kubernetes/community/pull/3534: to add the repo to sigs.yaml

After the postsubmit runs, I will grant access to the teams. Once that's done + the PR to add to sigs.yaml merges, we can close this issue.

[pwittrock]

@nikhita Should be good to go now.

[nikhita]

Teams have been granted access and https://github.com/kubernetes/community/pull/3534 has merged.

/close

[k8s-ci-robot]

@nikhita: Closing this issue.

In response to this:

Teams have been granted access and https://github.com/kubernetes/community/pull/3534 has merged.

/close

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.