Rename ProviderConfig to ProviderSpec

[dlipovetsky]

What this PR does / why we need it:
Renames ProviderConfig to ProviderSpec, to match the Spec/Status convention used in Kubernetes-style APIs.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #414

Special notes for your reviewer:
This is a breaking API change. The consensus in the meeting a couple months back was for in support of this change, but it can be put on hold for a while. I will test this change with https://github.com/kubernetes-sigs/cluster-api-provider-gcp/ and report back in this PR.

Release Note:

Breaking API Change: ProviderConfig renamed to ProviderSpec (#414)

[alvaroaleman]

Hm. Any chance we can increment to a v1alpha2 when merging this?

/ok-to-test

[roberthbailey]

@alvaroaleman - why do you want to increment the api version? Right now, with a single api version, we don't have to worry about version translation, which isn't yet a feature of CRDs. Are you suggesting that we move to v1alpha2 and drop v1alpha1?

[roberthbailey]

/lgtm
/approve
/hold

Holding on resolution of @alvaroaleman's question.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dlipovetsky, roberthbailey

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 [roberthbailey]

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

[alvaroaleman]

@roberthbailey

why do you want to increment the api version? Right now, with a single api version, we don't have to worry about version translation, which isn't yet a feature of CRDs. Are you suggesting that we move to v1alpha2 and drop v1alpha1?

Yes exactly that, to a) make everyone aware there is a pretty breaking change b) allow folks to build their own migration if they choose to

[roberthbailey]

@dlipovetsky - are you ok waiting to merge this until we can discuss during the weekly meeting next Wed about changing the apiversion?

[dlipovetsky]

@roberthbailey Absolutely ok with discussing it at the meeting, thanks. I'll also try to verify using the GCP provider before then.

[dlipovetsky]

I rebased. As part of the rebase, I renamed Config->Spec in the newly added MachineClass types.

[dlipovetsky]

@roberthbailey I think my plan to try out this change with the GCP provider was too ambitious. I started working on this, but I noticed that the GCP provider was vendoring https://github.com/pwittrock/cluster-api, and I'm not changing to my branch will be straightforward.

Is it reasonable to merge this PR and let providers update later?

[roberthbailey]

I sent kubernetes-sigs/cluster-api-provider-gcp#49 to update the vendored dependency.

But either way, the only real way to test your change in that repo is to change the source though. You need to add a constraint to Gopkg.toml locally, run dep ensure -update sigs.k8s.io/cluster-api to pull in your changes, and then you can test. Something like

[[constraint]]	
  name="sigs.k8s.io/cluster-api"	
  revision="insert git hash here"	
  source="https://github.com/dlipovetsky/cluster-api"

should do the trick.

[dlipovetsky]

@roberthbailey Thanks! I was less worried about dep, and more worried about the delta between pwittrock's branch and mine, which is rebased on master. Once your kubernetes-sigs/cluster-api-provider-gcp#49 lands, I'll try building gcp provider with my changes here.

[roberthbailey]

The PR in the gcp repo just merged.

[roberthbailey]

@dlipovetsky - have you had a chance to test yet?

We'd like to get this merged soon since the gitbook documentation is written assuming that this change has already gone in. :)