validate: add the validation of Resources.devices

[zhouhao3]

According to the following spec：

devices.type
devices.access

Signed-off-by: zhouhao [email protected]

[liangchenye]

resources.devices.access?

r.Resources.Devices[index].Access))

[wking]

I'd rather handle this sort of value validation by using the spec's JSON Schema (see the in-flight #197).

[Mashimiao]

LGTM
I think putting type or access value validation here is OK. It's hard to exactly check composition of r, w, m in JSON schema as I tried in runtime-spec/#690 and has been rejected.

[zhouhao3]

@liangchenye @mrunalp PTAL

[wking]

On Fri, May 05, 2017 at 02:51:31AM -0700, Ma Shimiao wrote: It's hard to exactly check composition of r, w, m in JSON schema as I tried in runtime-spec/#690 and has been rejected.

opencontainers/runtime-spec#690 was a stronger check than what we're checking here (since as of f6e16e8 this allows more than three characters). That PR wasn't closed because of a JSON Schema limitation, it was closed because the spec doesn't like carrying kernel limits (even though these particular limits are still listed in the spec [1]). But I don't think “included in the spec but not in the JSON Schema” is a particularly consistent position, so I'd rather revisit the JSON Schema approach to this or drop the valid-value listing from the spec Markdown. Either way, I don't think we need a Go check for these values in runtime-tools. [1]: https://github.com/opencontainers/runtime-spec/blame/v1.0.0-rc5/config-linux.md#L223

[zhouhao3]

ping @liangchenye @mrunalp

[zhouhao3]

@liangchenye @mrunalp PTAL

[liangchenye]

We can drop this kind of validation when the JSON schema validation is adopted in runtime-tools.
Open #453 to track this.

@q384566678 @Mashimiao will you try to integrate that?

[liangchenye]

LGTM

[Mashimiao]

LGTM

[zhouhao3]

@liangchenye I will try to do this.