Range-checking for generate options

[wking]

Many config settings have smaller legal ranges than their Go type implies (e.g. swappiness from 0 to 100). We should check for this and error out if users supply invalid values.

[haiyanmeng]

Here are some options we may need to check:

1. --uid: should be [0, the value in /proc/sys/kernel/overflowuid];
2. --gid: should be [0, the value in /proc/sys/kernel/overflowgid];
3. --groups: should check whether the totally supplementary groups is more than the value defined in /proc/sys/kernel/ngroups_max;
4. --uidmappings;
5. --gidmappings;
6. --linux-cpu-shares;
7. --linux-cpu-period;
8. --linux-cpu-quota;
9. --linux-realtime-runtime (maybe);
10. --linux-realtime-period (maybe);
11. --linux-mem-swappiness;

[wking]

With a granular-enough validate API, the generate checks can be:

1. Save the current value
2. Write the proposed value
3. Run the most granular validation command possible to cover the new
   setting.
4. On failure, restore the original value and raise an error.

[haiyanmeng]

@wking , for start, we can just check whether the user's setting is within the acceptable range. If it is not, return an error informing the user of the valid range and any other useful info which can help the user understand the problem and the correct setting.

[haiyanmeng]

@wking , @mrunalp , if you do not mind, I can work on a PR and come up with a first version of code to tackle this issue. Then we can discuss whether the PR is good enough.

[wking]

On Fri, Aug 05, 2016 at 08:21:38PM -0700, hmeng-19 wrote:

@wking , for start, we can just check whether the user's setting is
within the acceptable range.

This can probably be done with something like 1, where you use the
config file's ociVersion to pull in the appropriate version of the
schema (opencontainers/runtime-spec#490). That lets us centralize the
effort of maintaining the limits in runtime-spec.

[wking]

On Fri, Aug 05, 2016 at 11:12:44PM -0700, W. Trevor King wrote:

This can probably be done with something like [1], where you use the
config file's ociVersion to pull in the appropriate version of the
schema (opencontainers/runtime-spec#490). That lets us centralize
the effort of maintaining the limits in runtime-spec.

This approach now has a PR in #197, although with that PR it's only
being used for ‘validate’. To use it in ‘generate’, we'd need either:

a. A way to validate against a particular subset of the schema.
b. To insert the proposed setting in a valid template, and validate
that template against the full schema.

(a) seems more efficient and elegant (no wasted cycles validating the
known-good untouched portions of the template), but I'm not clear on
how to trigger subset-of-schema validation.

(b) is a sledgehammer, but with generate.New(os) in #194, it seems
like it would be easy to implement.

And a stable validation API that could sit in front of (a) or (b)
would be best, because then we could alter the implementation as we
found better approaches without impacting consumers. But I can't
think up an API without per-struct functions like:

func ValidateProcessUser(obj *rspec.User, field *string) error

following pattern like:

func ValidateSTRUCT(obj *STRUCT, field *string) error

And there are 32 structs in runtime-spec's config.go that you'd need
helpers for. I guess you could do something fancy with introspection
and have:

func Validate(obj interface{}, field *string) error

but while that makes for a convenient API, implementation would be
more tedious and static type checking might not be possible.