Use yaml.UnmarshalStrict everywhere

[alvaroaleman]

What this PR does / why we need it:

This PR makes us use yaml.UnmarshalStrict everywhere. This has the advantage that unknown fields cause an error instead of being silently dropped.

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 #

Special notes for your reviewer:

Documentation:

Does this PR introduce a user-facing change?:

[ACTION REQUIRED] Kubermatic now doesn't accept unknown keys in its config files anymore and will crash if an unknown key is present
[ACTION REQUIRED] BYO datacenters now need to be specific in the `datacenters.yaml` with a value of `{}`, e.G `bringyourown: {}`

/assign @zreigz
/assign @nikhita

[nikhita]

@alvaroaleman could this lead to compatibility issues with older versions if they persisted unknown fields?

[alvaroaleman]

I think we never removed fields so far, we only added stuff. Can you config @mrIncompetent ?

[mrIncompetent]

@alvaroaleman

Can you config @mrIncompetent ?

How do you wan't me to be configured?

[alvaroaleman]

/pony typo

[kubermatic-bot]

@alvaroaleman:

In response to this:

/pony typo

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.

[mrIncompetent]

We replaced AMI with ImageList within the AWS spec.
I assume there might be old files out there which might still contain the AMI field.

So we might want to think about something to ease the operators(The human, not the controller) life in case such an error gets triggered.
Maybe print an error linking to a docs page in case the unmarshal fails?

[alvaroaleman]

Maybe print an error linking to a docs page in case the unmarshal fails?

Not sure, I mean the error will contain a "field bla was not found", IMHO that is pretty self-explanatory.

IMHO compatibility is mainly an issue if we would want to allow ppl to use the same config files for multiple versions of Kubermatic, but that is not the case. The config files are supposed to be compatible with exactly one version of Kubermatic. And IMHO the burden of forcing everyone to clean up is not a bad thing at all, since it keeps everything tidy

Goes to the secrets repo and removes unknown field "provider"

[zreigz]

the API can not start:

{"level":"fatal","time":"2019-07-11T15:01:29.330+0200","caller":"kubermatic-api/main.go:78","msg":"failed to create and initialize providers","error":"failed to load datacenter yaml \"/home/lukasz/go/src/github.com/kubermatic/secrets/seed-clusters/dev.kubermatic.io/datacenters.yaml\": error unmarshaling JSON: while decoding JSON: json: unknown field \"provider\""}

[alvaroaleman]

Yes, I am fixing up our datacenters.yaml. Note even our unittests pass with this 😬

[mrIncompetent]

A nice customer experience would be if the customer knows ahead of time if the datacenters.yaml must be checked.
So far we never had a release note stating that the datacenters.yaml must be modified or kubermatic throws errors. Now we require changes on that file and those should be documented in upgrade docs + a release note.

[alvaroaleman]

A nice customer experience would be if the customer knows ahead of time if the datacenters.yaml must be checked.

Yes, I absolutely agree. Will add an [Action Needed] release note

[zreigz]

there is another error:

{"level":"fatal","time":"2019-07-11T16:11:26.242+0200","caller":"kubermatic-api/main.go:78","msg":"failed to create and initialize providers","error":"failed to load datacenter yaml \"/home/lukasz/go/src/github.com/kubermatic/secrets/seed-clusters/dev.kubermatic.io/datacenters.yaml\": error unmarshaling JSON: while decoding JSON: json: unknown field \"region\""}

[alvaroaleman]

/retest

[alvaroaleman]

Tests passed, ptal @mrIncompetent @zreigz

[zreigz]

/approve no-issue

[mrIncompetent]

/lgtm
/approve

[kubermatic-bot]

LGTM label has been added.

Git tree hash: c04c48f616dccf4ee2270671861d0d0322b57e29

[kubermatic-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mrIncompetent, zreigz

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 [mrIncompetent,zreigz]

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