host-specific and platform overlapped in validation

[liangchenye]

While reviewing #187,
I checked both generate and validate logic.

In validate.go, we have both 'host-specific' and 'platform',
I think we should overwrite the platform when we have 'host-specific' option.

[liangchenye]

Fix #414
PTAL @mrunalp @hqhq @Mashimiao

[liangchenye]

fixed, close

[wking]

On Thu, Jul 06, 2017 at 02:58:39AM +0000, 梁辰晔 (Liang Chenye) wrote: In validate.go, we have both 'host-specific' and 'platform', I think we should overwrite the platform when we have 'host-specific' option.

Can we re-open this? I'd rather have logic like: a. If --platform is set… a. If --host-specific is set… a. If the platform value matches the host, proceed with host-specific validation. b. If the platform value doesn't match the host, generate a usage error (a “we can't do that on this host” error, not a “that config is invalid” error). b. If --host-specific is not set, run the host-independent checks for that platform. b. If --platform is not set, default to the current host platform. a. If --host-specific is set, proceed with host-specific validation. b. If --host-specific is not set, run the host-independent checks for that platform. The difference is that with #415, we're using the a.a.a approach for both a.a.a and a.a.b. And we're currently assuming ‘linux’ for --platform in b.b instead of my proposal, which is less convenient for non-Linux users (I expect validating Linux configs using non-Linux hosts to be less common than validating same-platform configs on non-Linux hosts).

[liangchenye]

+1 for add a 'warning' to fix a.a.b.