Validate cluster config

[johananl]

General

We should consider adding validation for cluster configuration. At the moment we catch some configuration problems (mainly wrong HCL syntax), however we probably want to have more Lokomotive-specific validation.

The rationale for this task:

• Being able to catch config problems early rather than starting to execute only to discover that we have some missing/wrong piece of config later down the line. If validation passes, the cluster should deploy (barring any run time issues).
• Having one place to validate interaction between various knobs. Configuration can grow complex over time, and various features and knobs can have unexpected interactions. Having one place to validate the config and write unit tests for all config-related aspects can make this aspect much easier.
• Being able to provide similar-looking, meaningful errors to the user.
• Less chance for missed test cases when modifying knobs.

Right now we have validation code scattered throughout the codebase. Examples:

• https://github.com/kinvolk/lokomotive/blob/8e0529a0b5264e12a66bbd24a0f149a719473c97/pkg/platform/packet/packet.go#L133-L136
• https://github.com/kinvolk/lokomotive/blob/8e0529a0b5264e12a66bbd24a0f149a719473c97/pkg/components/cluster-autoscaler/component.go#L239-L250
• https://github.com/kinvolk/lokomotive/blob/8e0529a0b5264e12a66bbd24a0f149a719473c97/pkg/dns/dns.go#L62-L77

Implementation

Important points to consider:

• Config validation should be centralized. For example, we want to validate component configuration even if the logic for deploying components is triggered after cluster installation had been completed.

I think we can extract all config-related logic from the various packages and move them into pkg/config. There we can validate things centrally and have one place for all config-related unit tests. We can then have a nice state where any value used in platform or component code can be treated as validated, which could simplify the code and likely remove some ad-hoc validation checks. I think a good rule of thumb could be - if it has an hcl:"stuff" kind of tag, it should be in pkg/config. The other packages can contain package-specific data structure which are derived from those in the config package, but shouldn't deal with unmarshalling HCL and/or config validation.

[invidian]

@ipochi #359 would also address that I think.