Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Work tracker for moving ComponentConfig types to staging repos #67233

Closed
15 tasks done
stewart-yu opened this issue Aug 10, 2018 · 7 comments
Closed
15 tasks done

Work tracker for moving ComponentConfig types to staging repos #67233

stewart-yu opened this issue Aug 10, 2018 · 7 comments
Labels
area/api Indicates an issue on api area. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. sig/architecture Categorizes an issue or PR as relevant to SIG Architecture. sig/cloud-provider Categorizes an issue or PR as relevant to SIG Cloud Provider. sig/cluster-lifecycle Categorizes an issue or PR as relevant to SIG Cluster Lifecycle. sig/network Categorizes an issue or PR as relevant to SIG Network. sig/node Categorizes an issue or PR as relevant to SIG Node. sig/scheduling Categorizes an issue or PR as relevant to SIG Scheduling.
Milestone

Comments

@stewart-yu
Copy link
Contributor

stewart-yu commented Aug 10, 2018

Now, we're making great progress with implementing the KEP about moving ComponentConfig types to staging repos kubernetes/community#2354, and there are many PRs that are in progress in both in parallel and serial. Here's a work tracker for related PRs. There is a follow-up PR to the initial KEP to accept this KEP as implementable as well: kubernetes/community#2515

First, create required meta-repos:

Preparation work for making the code moves possible:

kube-scheduler

kube-controller-manager:

kube-proxy

kubelet:

General cleanup PR after all the changes:

@k8s-ci-robot k8s-ci-robot added the needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. label Aug 10, 2018
@neolit123
Copy link
Member

/sig api-machinery
/area api

@k8s-ci-robot k8s-ci-robot added sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. area/api Indicates an issue on api area. and removed needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Aug 10, 2018
@luxas luxas changed the title Some PR need to tracking about componentConfig API Work tracker for moving ComponentConfig types to staging repos Aug 12, 2018
@luxas luxas added sig/cluster-lifecycle Categorizes an issue or PR as relevant to SIG Cluster Lifecycle. sig/network Categorizes an issue or PR as relevant to SIG Network. sig/scheduling Categorizes an issue or PR as relevant to SIG Scheduling. sig/node Categorizes an issue or PR as relevant to SIG Node. sig/architecture Categorizes an issue or PR as relevant to SIG Architecture. sig/cloud-provider Categorizes an issue or PR as relevant to SIG Cloud Provider. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. labels Aug 12, 2018
@luxas luxas added this to the v1.12 milestone Aug 12, 2018
@Lion-Wei
Copy link

I can help for kube-proxy part. : )
/assign

@fedebongio
Copy link
Contributor

/cc @cheftako @yliaog @roycaihw

@luxas
Copy link
Member

luxas commented Aug 22, 2018

For reference, this KEP has been moved to the implementable stage via this PR: kubernetes/community#2515, so we are good to go for all components here 💯

@dims
Copy link
Member

dims commented Aug 24, 2018

Related to #57618

k8s-github-robot pushed a commit that referenced this issue Aug 28, 2018
Automatic merge from submit-queue (batch tested with PRs 64597, 67854, 67734, 67917, 67688). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.

Move kubeproxy ComponentConfig external types to `k8s.io/kube-proxy`

**What this PR does / why we need it**:
This PR implements most of kubernetes/community#2354 for the kube-proxy.
The PR:
- Moves k8s.io/kubernetes/pkg/proxy/apis/kubeproxyconfig as-is to k8s.io/kubernetes/pkg/proxy/apis/config as agreed
- Moves the external types to the new staging repo k8s.io/kube-proxy, in the k8s.io/kube-proxy/config/v1beta1 package.
- Makes k8s.io/kubernetes/pkg/proxy/apis/config/v1beta1 source the types from k8s.io/kube-proxy/config/v1beta1. The defaulting and conversion code is kept in this package as before.
- All references to these packages have been updated.

Ref #67233

**Special notes for your reviewer**:

**Release note**:
```release-note
kube-proxy v1beta1 external ComponentConfig types are now available in the `k8s.io/kube-proxy` repo
```
k8s-github-robot pushed a commit that referenced this issue Sep 6, 2018
Automatic merge from submit-queue (batch tested with PRs 68171, 67945, 68233). If you want to cherry-pick this change to another branch, please follow the instructions here: https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md.

Move the CloudControllerManagerConfiguration to an API group in `cmd/`

**What this PR does / why we need it**:
This PR is the last piece of #67233.
It moves the `CloudControllerManagerConfiguration` to its own `cloudcontrollermanager.config.k8s.io` config API group, but unlike the other components this API group is "private" (only available in `k8s.io/kubernetes`, which limits consumer base), as it's located entirely in `cmd/` vs a staging repo.
This decision was made for now as we're not sure what the story for the ccm loading ComponentConfig files is, and probably a "real" file-loading ccm will never exist in core, only helper libraries. Eventually the ccm will only be a library in any case, and implementors will/can use the base types the ccm library API group provides. It's probably good to note that there is no practical implication of this change as the ccm **cannot** read ComponentConfig files. Hencec the code move isn't user-facing.

With this change, we're able to remove `pkg/apis/componentconfig`, as this was the last consumer. That is hence done in this PR as well (so the move is easily visible in git, vs first one "big add" then a "big remove"). The only piece of code that was used was the flag helper structs, so I moved them to `pkg/util/flag` that I think makes sense for now.

**Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*:
ref: kubernetes/community#2354

**Special notes for your reviewer**:

This PR builds on top of (first two commits, marked as `Co-authored by: @stewart-yu`) #67689

**Release note**:

```release-note
NONE
```
/assign @liggitt @sttts @thockin @stewart-yu
@stewart-yu
Copy link
Contributor Author

all fixed in v1.12, so close it now
/close

@k8s-ci-robot
Copy link
Contributor

@stewart-yu: Closing this issue.

In response to this:

all fixed in v1.12, so close it now
/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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/api Indicates an issue on api area. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. sig/architecture Categorizes an issue or PR as relevant to SIG Architecture. sig/cloud-provider Categorizes an issue or PR as relevant to SIG Cloud Provider. sig/cluster-lifecycle Categorizes an issue or PR as relevant to SIG Cluster Lifecycle. sig/network Categorizes an issue or PR as relevant to SIG Network. sig/node Categorizes an issue or PR as relevant to SIG Node. sig/scheduling Categorizes an issue or PR as relevant to SIG Scheduling.
Projects
None yet
Development

No branches or pull requests