runtime.md: only required properties are MUST applied

[hqhq]

Address the issue mentioned in:
#405 (comment)

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 h.huangqiang@huawei.com

[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 7c2514b 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. [1]: https://github.com/opencontainers/runtime-spec/blob/v1.0.1/config.md#extensibility [2]: https://github.com/opencontainers/runtime-spec/blob/05da00bc76e1746276e977ab45957ab39c31c73a/spec.md#property-specification 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

[wking]

... now vm based container has to figure out how they can be ignored by other runtimes :(

I think the way to do that is to be declarative:

• Declare a vm platform (I would have preferred "protocol", see config: Link platform:"…" JSON tags with ~~protocol~~ platform slugs #570).
• Provide a way for runtime-callers (including the certification suite) to determine platforms that the runtime claims to support. This could happen in docs/command-line-interface: Add Runtime CLI Spec runtime-tools#321 or similar, possibly with a generic "list your platforms" operation defined in runtime.md.
• Provide a way for runtime-callers to select target platforms if the runtime supported more than was needed (e.g. --platform vm,linux), with the same tools/spec location as the previous point.

Would you need anything else?

[wking]

I feel like this is the idea that the extensibility section was trying to convey,and which I was trying to tighten up in #680. Instead of attempting to repeat the condition here, I would rather update that section to cover the non-ignore-ability of properties defined by this spec for that target platform (even ones like process.rlimits, which lie outside of linux). Text here that references that section would be great, though. Maybe something like:

All of the [recognized properties](config.md#extensibility) configured in [`config.json`](config.md) except for [`process`](config.md#process) MUST be applied.

with wording in the extensibility section and/or glossary to more formally define "recognized properties"?

[hqhq]

@wking I don't think the extensibility section conveys this. In my understanding, unknown property means the property is not defined in spec, not the property that runtime doesn't support (if we have different understanding, maybe glossary for unknown property is needed?).

[wking]

I don't think the extensibility section conveys this.

Not yet (#680 is me trying to tighten part of it down). I'm staying that the extensibility section is where we already attempt to cover this sort of thing, not that it already covers the hole you've identified here.

I'd rather tighten up the extensibility section to cover all of the “which properties can the runtime ignore?” conditions, because if it covers a subset, and runtime.md adds a few more, then config authors might read the extensibility section, think they understand what the runtime can ignore, and then be surprised when it also ignores something that was added in runtime.md. It's easier to understand if we collect all the conditions in one place.

[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.