You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In 718f9f3 (minor narrative cleanup regarding config compatibility,
2017-01-30, #673) we got:
Implementations MUST error out when invalid values are encountered
and MUST generate an error message and error out when encountering
valid values it chooses to not support
In c763e64 (config: Move valid-value rules to their own section,
2017-02-07, #681), I'd moved that out into the current "Valid values"
section with the line I'm removing in this commit. However, giving
runtimes a blanket clause to ignore valid values makes it harder to
use runtimes, because you can't be sure an OCI-compliant runtime
supports the spec-defined value you need [1].
There have been concerns about requiring runtimes to support values
which are not supported by the host system [2]. But since 766abd6
(runtime.md: Require 'create' to fail if config.json asks for the
impossible, 2016-09-08, #559) we've had runtime.md wording that gives
the runtime the ability to compliantly die in those cases. That text
had a wording tweak in 72e8062 (runtime: Explicitly make process.*
timing implementation-defined, 2017-02-27, #700), and is now:
If the runtime cannot apply a property as specified in the
configuration, it MUST generate an error and a new container MUST
NOT be created.
As it stands both before and after this commit, a runtime can *still*
die in 'create' because it cannot apply values supported by the host.
This commit is just a step towards requiring runtimes to support as
many values as the host supports; it doesn't get us all the way there.
Many properties could use clearer runtimes-MUST-support wording for
those values, but we can sort those out on a per-property basis in
follow-up work.
And runtimes are still allowed to support extention values not defined
in the spec (e.g. new capability types, or mount options, or
whatever). Like all extentions, it is up to the runtime and
runtime-caller to negotiate support in those cases.
[1]: #813 (comment)
[2]: #673 (comment)
Signed-off-by: W. Trevor King <[email protected]>
0 commit comments