validation: add linux resource check

[Mashimiao]

Signed-off-by: Ma Shimiao mashimiao.fnst@cn.fujitsu.com

[wking]

I think we should leverage runtime-spec's JSON Schema for this sort of thing. Validation should validate against the JSON Schema, and then run additional checks that can't be addressed in JSON Schema (like your limit/swap comparison below).

[Mashimiao]

On 08/18/2016 12:13 AM, W. Trevor King wrote:

I think we should leverage runtime-spec's JSON Schema https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc1/schema/schema-linux.json#L64-L69 for this sort of thing. Validation should validate against the JSON Schema, and then run additional checks that can't be addressed in JSON Schema (like your limit/swap comparison below).
Well, I didn't know about runtime-spec's JSON Schema before...
It seems it has function to validate min and max value.
But I think it's a little inconvenient to validate bundle by two tools as ocitools and this one.
I think ocitools should have this functions when validating bundle.
can we merge this into ocitools?

[wking]

On Wed, Aug 17, 2016 at 06:28:27PM -0700, Ma Shimiao wrote:

I think ocitools should have this functions when validating bundle.
can we merge this into ocitools?

I don't think we need to merge the tool, since 1 is so tiny. My
preferred approach would be to have something like
opencontainers/runtime-spec#490 so we could pull the schema JSON from
opencontainers.org (if folks ever get around to publishing it there ;)
or raw.githubusercontent.com (if they don't). The ocitools validate
flow would be:

1. Invoked on a given config.
2. Find the ociVersion.
3. Figure out the URL for the associated JSON Schema (e.g. 2).
4. Have xeipuuv/gojsonschema or similar use that schema to validate
   the config.
5. Use Go (or Python Use Python's unittest for validating bundles and configurations? #98) to perform the checks that JSON Schema can't
   handle (e.g. multi-param checks, host-specific checks, …).

[Mashimiao]

It looks like a good advice, we can implement it later.
Before implementing that, I think keep min and max check is OK.
Maybe they are some short of thing, but Ocitools and runtime schema are two projects and ocitools does not have these yet.

[wking]

On Wed, Aug 17, 2016 at 10:27:06PM -0700, Ma Shimiao wrote:

Maybe they are some short of thing, but Ocitools and runtime schema
are two projects and ocitools does not have these yet.

ocitools depends strongly on runtime-spec already, both for the
Markdown spec and the Go types. I don't see any new issues if we
start depending on the JSON Schema it provides as well. I'll file a
PR that adds a JSON Schema initial validation pass tonight.

[Mashimiao]

If so, I'm glade to remove these short of value checks

[wking]

On Wed, Aug 17, 2016 at 10:48:39PM -0700, Ma Shimiao wrote:

@@ -381,6 +386,47 @@ func checkLinux(spec rspec.Spec, rootfs string, hostCheck bool) (msgs []string)
return
}

+func checkLinuxResources(r rspec.Resources, hostCheck bool) (msgs []string) {

• logrus.Debugf("check linux resources")

• if r.OOMScoreAdj != nil && (int(_r.OOMScoreAdj) < -1000 || int(_r.OOMScoreAdj) > 1000) {

•   msgs = append(msgs, fmt.Sprintf("OOMScoreAdj range is from -1000 to 1000"))
  

If so, I'm glade to remove these short of value checks

Filed against v1.0.0.rc1 as #197. Figuring out the right schema URL
for a -dev version is unclear to me, so we might have to wait on
forward-porting until runtime-spec cuts a v1.0.0-rc2.

[Mashimiao]

removed short of min and max check. implemented them in opencontainers/runtime-spec#533

[wking]

On Thu, Aug 18, 2016 at 12:45:38AM -0700, Ma Shimiao wrote:

removed short of min and max check.

9cad4d8 looks good to me.

I have a slight preference for:

func checkLinuxResources(r *rspec.Resources, …) …

over this PR's:

func checkLinuxResources(r rspec.Resources, …) …

because it lets us handle the nil check inside. But we can look at
that sort of thing when we pull the validation out into a library (or
replace it with Python, #98 ;).

[mrunalp]

LGTM