runtime.md: only required properties are MUST applied

[hqhq]

Address the issue mentioned in: https://github.com/opencontainers/runtime-spec/pull/405#issuecomment-342730002

We already doing this in runc as we can run a container with a config which has windows entry. And this is the right way to handle it.

Signed-off-by: Qiang Huang [email protected]

[wking]

This is moving against #680 and #813. Things like “Linux runtime $X ignores Windows property $Y” are acceptable, because the runtime-caller should know they are calling a Linux runtime and expect it to ignore those “unknown to their platform” properties based on our current 1:

Runtimes that are reading or processing this configuration file MUST NOT generate an error if they encounter an unknown property. Instead they MUST ignore unknown properties.

And, although we don't currently document it anywhere (#747), I'd always read our property-specification REQUIRED/OPTIONAL as “… for configurations” not “… for runtimes” 2.

I think the wording you have in 7c2514be severely weakens the spec (“We're sorry your container clobbered your filesystem, but our compliant, non-Windows runtime silently ignores the OPTIONAL ‘root.readonly’ [3]”). But even if the maintainer consensus is that such weakening is a good idea, I would still strongly caution against overloading the requirement-level portion of our property specifications to cover both runtime and configuration requirements.

Which still doesn't quite spell out the target. [3]: https://github.com/opencontainers/runtime-spec/blob/v1.0.1/config.md#root

[hqhq]

@wking I've updated this PR to allow ignore platform specific configuration, now vm based container has to figure out how they can be ignored by other runtimes :( @sameo

[sameo]

Declare a vm platform (I would have preferred "protocol", see #570).

I don't think a VM is a platform. They're almost orthogonal concepts, given that all existing OCI platforms support hardware virtualization, i.e. you could potentially have a vm platform and a {linux,solaris,windows} platform.

[wking]

I don't think a VM is a platform.

Which is why I prefer "protocol", but the maintainers wanted "platform".

... you could potentially have a vm platform and a {linux,solaris,windows} platform.

Which is why I used vm,linux in my example.

And taking a step back, this feels like we're gradually circling back to #15.

[vbatts]

house keeping: this use of MAY would not clear up the situation in the future where platform supportable features overlap (i.e. Windows Subsystem for Linux (WSL) possibly running linux container tech on a windows host). VM is not a platform, but this language should not loosen edge-cases. I'm inclined to close this issue for now.