Refactor to use legacy cloud provider

[nckturner]

• This is starting with v1.15.0
• This is important because we need to start by using legacy-cloud-provider so that we don't fork this repo from in-tree before people migrate. That approach would make migration much more difficult.

What type of PR is this?

/kind cleanup

What this PR does / why we need it:

In order to start using this repo to build valid cloud-controller-manager binaries and begin adding tests, we need to migrate to the legacy-cloud-provider.

NONE

[nckturner]

/cc @M00nF1sh

[nckturner]

Followed openstack's approach, which involves defining the cobra command, and additionally redefining the initFuncs for each cloud controller.

[nckturner]

/cc @andrewsykim

[andrewsykim]

exit after printing version?

[andrewsykim]

If you call NewCloudControllerManagerCommand() in main.go, you should get all of this with it.

[nckturner]

Yeah I saw that. It would be easier but my plan was to start with this and then eventually replace/remove the dependencies on k/k, which I think will be easier if we start here.

[M00nF1sh]

I think this is an good starting point where we can iterate from :D

[M00nF1sh]

/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: M00nF1sh, nckturner

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [M00nF1sh,nckturner]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[geckofu]

Hi, I'm a newcomer and would like to contribute to this project. Where should I work on after this migration? In kubernetes' main repo staging area as the legacy-cloud-provider says?

[M00nF1sh]

@geckofu
For now, it's still kubernetes's main repo's staging area(which will be synced to legacy-cloud-provider and consumed by this project).
In the future, we'll gradually migrate off legacy-cloud-provider dependency.

[kapilt]

i feel like the better approach would have been to go in the opposite direction, ie have the legacy cloud in k8s main repo depend on the code in this repo. as is it just erases most of the progress made in moving the provider out of tree.

[andrewsykim]

@kapilt that's a good point but there's a few reasons for not importing this repo back from kubernetes/kubernetes:

• We have less control over the dependencies that are pulled into this repo that would eventually get pulled into all the core Kubernetes components. The existing legacy repo is already contained and we ensure that dep graph doesn't grow.
• It'll be harder to keep backwards compatibility if we are pulling in new changes here to core Kubernetes
• It's much easier to iterate this repo from what already exists because the legacy repo passes Kubernetes pre-checks in the main repo and we know have more confidence that what we are supporting out-of-tree should work for most users transitioning from in-tree.