Move cmd/cloud-controller-manager and its controllers to k8s.io/cloud-provider (staging)
andrewsykim opened this issue · comments
Right now, out-of-tree providers end up vendoring a lot of k8s.io/kubernetes because they need to import cmd/cloud-controller-manager. cmd/cloud-controller-manager should be easier to consume, ideally living in it's own repository or moved to k8s.io/cloud-provider.
Similar to what we did for in-tree providers (k8s.io/kubernetes/pkg/cloudprovider/providers) we need to start pruning some of the internal dependencies for cmd/cloud-controller-manager as a starting point
For v1.16: agree on design and future plans for migrating cmd/cloud-controller-manager to staging or an external repo.
/assign @timoreimann
@andrewsykim: GitHub didn't allow me to assign the following users: timoreimann.
Note that only kubernetes members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide
In response to this:
/assign @timoreimann
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.
After some thought, I'm in favor of moving cmd/cloud-controller-manager to k8s.io/cloud-provider/cmd/cloud-controller-manager.
I think its a good idea. We will need another extract to staging effort to make this work.
Look at https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/app/BUILD#L14, https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/app/apis/config/BUILD#L14 and https://github.com/kubernetes/kubernetes/blob/master/cmd/cloud-controller-manager/app/options/BUILD#L18 for an idea of what needs to be extracted.
Oh so happy to see this. Spent far too much time today because of this, and kindly helped by some go community people and of course @timoreimann.
@deitch - I'm filing the rest of the PRs before the 1.17 release, I expect the final move to happen in 1.18, this would leave a whole release for providers to migrate their imports.
@andrewsykim @cheftako @nckturner @craiglpeters et all does this timeline sound reasonable ?
Sounds good to me, let's put this as p0 for v1.18
Yup, 1.18 sounds like a reasonable timeline to me.
Related: Is there already an issue or a guide related to simplifying/streamlining options parsing?
We still use a IMHO pretty terrible way to parse options: https://github.com/apache/cloudstack-kubernetes-provider/blob/master/cmd/cloudstack-ccm/main.go#L45-L50
This was the only sensible way that I could find back when we forked, in part due to a lack of experience.
If not, I will gladly open a new issue.
k8s.io/kubernetes/cmd/cloud-controller-manager -> k8s.io/cloud-provider/cmd/cloud-controller-manager
k8s.io/kubernetes/pkg/controllers/{cloud,service,route} -> k8s.io/cloud-provider/controllers
/assign
/unassign @yastij
cc @cici37
/assign @cici37
/assign @cici37
/assign @cici37
For clarity, all of the internal deps of cmd/cloud-controller-manager:
k8s.io/kubernetes/cmd/controller-manager/app
k8s.io/kubernetes/pkg/api/legacyscheme
k8s.io/kubernetes/pkg/cloudprovider/providers
k8s.io/kubernetes/pkg/controller
k8s.io/kubernetes/pkg/controller/apis/config
k8s.io/kubernetes/pkg/controller/apis/config/v1alpha1
k8s.io/kubernetes/pkg/controller/cloud
k8s.io/kubernetes/pkg/controller/route
k8s.io/kubernetes/pkg/controller/service/config
k8s.io/kubernetes/pkg/controller/service/config/v1alpha1
k8s.io/kubernetes/pkg/controller/service
k8s.io/kubernetes/pkg/features
k8s.io/kubernetes/pkg/master/ports
k8s.io/kubernetes/pkg/util/configz
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
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
/remove-lifecycle stale
/lifecycle frozen
I am really glad to see this. Has documentation been updated? How do we update our downstream dependencies?
Thanks. I'm looking forward to it.
Fwiw though, this is technically breaking change at the Go package-level, but IMO this brekaing change is worth-while to cut k/k from the dep graph.
I maintain the Equinix (formerly Packet) CCM, I am super happy to rebuild with this cleanup. Breaking changes for the win here :-)