runtime-spec
runtime-spec copied to clipboard
opencontainers
config: Do not allow runtimes to ignore properties defined by the spec
Otherwise a runtime could silently ignore a property it didn't want to implement, which would be confusing for runtime callers. This closes a potential loophole in the restriction from #559.
This would benefit from the clearer platform/protocol slug language in #570, so if #570 lands first I'll rebase this PR around it and tighten the “target platform” wording here.
This would benefit from the clearer platform/protocol slug language in #570…
#570 landed, and I've floated some work tying settings to platforms in #747. I recommend reviewing #747 first, and then I'll reroll this if/when that lands.
IMO we can decide on the specifics of this edge case post-1.0
@crosbymichael what's your opinion on clarifying this being a 1.0 or 1.1 concern?
On Wed, May 24, 2017 at 08:48:07AM -0700, v1.0.0.batts wrote:
let's make a decision on whether this is required for v1.0.0
I don't think the current spec is particularly clear, but if folks read the current wording like I do 1 and we end up landing wording settling on @tianon's interpretation 1, that would be a breaking change (e.g. configs targeting Linux that set process.user.username would go from being legal to being illegal). So if we punt to post-1.0, settle on @tianon's interpretation, and feel like my current reading has any merit, we'd have to bump to 2.0 when we landed wording for @tianon's interpretation.
Rebased around #850 with 19ed44c → ffa1718, changing the “target platform” link from #platform to spec.md#platforms.
Does this mean that everything that cannot be defined for one platform must be moved to platform specific code or explicitly annotated?
eg currently root.readonly is not annotated as every platform except Windows.
On Tue, Jun 27, 2017 at 07:39:23AM -0700, Justin Cormack wrote:
Does this mean that everything that cannot be defined for one platform must be moved to platform specific code or explicitly annotated?
Yes! For example, in rc6 we have wording restricting process.user.uid, etc. to POSIX platforms 1 and wording restricting everything in config-linux.md to Linux 2.
To make those restrictions more explicit, we could declare them in the property specification 3, but that approach was rejected 4.
Regardless of whether the declaration is on the property itself or somewhere else in the spec, I think we need to be (and generally are) very clear about which platforms a property is defined for. Not clearly documenting that association will make life confusing for config authors. For example, a Linux or Solaris runtime that ignores process.rlimits would violate at least [5,6,7,8].