REQUEST: Creation of KEP 14 repos

[sttts]

To implement KEP 14, we need a couple of repos.

New Repo

• cloud-controller-manager
• kube-controller-manager
• kube-scheduler
• kubelet
• kube-proxy

Which Organization should it reside

kubernetes

Note that these are "staging repositories", i.e. they are published by the https://github.com/kubernetes/publishing-bot and therefore must be in the kubernetes org.

Who should be provided access to this repository

We need admin access for the stage-bots team, compare:

We need branch settings like:

Approvals

KEP 14: https://github.com/kubernetes/community/blob/master/keps/sig-cluster-lifecycle/0014-20180707-componentconfig-api-types-to-staging.md

Additional context for request

The staging repositories have been created in the staging/ directory of the k/k repo, all approved by top-level approvers @jbeda and @thockin.

/cc @luxas @stewart-yu

[cblecker]

@sttts Has sig-arch approved of new core repos? Was there a meeting agenda item or a mailing list thread where they do?

cc: @jdumars @bgrant0607

[sttts]

@cblecker the KEP was approved which proposed these repos.

[cblecker]

Looks like this is slated for discussion in sig-arch on Thursday
kubernetes/community#2627

[sttts]

@cblecker Sig-arch approved them: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/kubernetes-sig-architecture/x_-L4dlwbeU/qwlEd64kBgAJ

[spiffxp]

• https://github.com/kubernetes/cloud-controller-manager
• https://github.com/kubernetes/kube-controller-manager
• https://github.com/kubernetes/kube-proxy
• https://github.com/kubernetes/kube-scheduler
• https://github.com/kubernetes/kubelet

[spiffxp]

/assign
I believe this is done but I'll leave this open to confirm since this is staging

[spiffxp]

It's also unclear to me whether/where these repos should fall in sigs.yaml?

[stewart-yu]

thanks, but seems no need to create repo for cloud-controller-manager now. @spiffxp 😀
/cc @sttts

[GeorgeGuo2018]

https://github.com/kubernetes/kube-controller-manager
this repo is empty now, what should i do if my older projects referred package from this repo?
Any reply would be appreciated,thx.

[sttts]

thanks, but seems no need to create repo for cloud-controller-manager now.

@stewart-yu thanks for the correction. Yes, we keep those types in the cmd package because the future of the binary is not clear.

[sttts]

this repo is empty now, what should i do if my older projects referred package from this repo?
Any reply would be appreciated,thx.

@GeorgeGuo2018 I will update github.com/kubernetes/publishing-bot and it will fill that repo.

Which "older projects" do you refer to?

[sttts]

@spiffxp we have the OWNERS files in there. Isn't that enough? Listing those repos in sigs.yaml in addition sounds equivalent.

[sttts]

@spiffxp as @stewart-yu correctly noted, cloud-controller-manager is not used. You can delete it again.

[spiffxp]

@sttts every other repo that comes out of staging is listed in sigs.yaml as belonging to a sig, egs:

sig-api-machinery has this entry

- name: universal-machinery # i.e., both client and server
      owners:
      - https://raw.githubusercontent.com/kubernetes/apimachinery/master/OWNERS
      - https://raw.githubusercontent.com/kubernetes/kubernetes/master/staging/src/k8s.io/apimachinery/OWNERS

sig-architecture has this entry

- name: api
      owners:
      - https://raw.githubusercontent.com/kubernetes/api/master/OWNERS
      - https://raw.githubusercontent.com/kubernetes/kubernetes/master/staging/src/k8s.io/api/OWNERS

I don't know if the intent is to move to a world where each component is owned by a different sig, eg:

• sig-node owns kubelet
• sig-network owns kube-proxy
• sig-apps owns kube-controller-manager
• sig-api-machinery owns kube-apiserver
• sig-scheduling owns kube-scheduler

or, if sig-archtecture owns the root of each component, with individual sigs owning packages within (eg: sig-architecture owns api, but sig-apps owns the workload apis)

[sttts]

@spiffxp I wasn't aware that we link OWNERS files there. So of course the new repos belong into that file 👍

[spiffxp]

Current status:

• I removed cloud-controller-manager
• The other repos look to be synced by publishing-bot now
• I have yet to confirm that the repos have been added to sigs.yaml

[spiffxp]

I chatted with @sttts offline, the repo descriptions have been changed

Just waiting for a sigs.yaml PR to close this out

[luxas]

I don't know either whether we want the specialized SIG (e.g. node) to own all of the k8s.io/kubelet repo or if we want it to own e.g. pkg/ and cmd/ only?
That really dictates the structure of the sigs.yaml PR. Any preferences?

[spiffxp]

Having sig-arch own root and specialized sigs own different packages was one of the suggestions I made above. I have no strong preference other than an option get chosen. I will ask the sig-arch mailing list

[spiffxp]

kubernetes-sig-arch@ thread

[spiffxp]

So far I have received two responses, both of which seem to suggest the sig-arch root / sig-foo subdirs approach.

[luxas]

The final piece of this was fixed with kubernetes/kubernetes#70453, closing
/close

[k8s-ci-robot]

@luxas: Closing this issue.

In response to this:

The final piece of this was fixed with kubernetes/kubernetes#70453, closing
/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.