-
Notifications
You must be signed in to change notification settings - Fork 554
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
config: Do not allow runtimes to ignore properties defined by the spec #680
base: main
Are you sure you want to change the base?
Conversation
We are going to figure out a better way to word this. |
config.md
Outdated
@@ -415,6 +415,7 @@ Values MAY be an empty string. | |||
## Extensibility | |||
Implementations that are reading/processing this configuration file MUST NOT generate an error if they encounter an unknown property. | |||
Instead they MUST ignore unknown properties. | |||
Properties defined for the [target platform](#platform) by the [declared version](#specification-version) of this specification MUST NOT be ignored. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tianon questioned the “for the target platform” portion of this in #819, saying he would be surprised if the runtime did not error when the config set a property that this spec only defined for another platform (e.g. the Windows-only process.user.username
in a Linux config). I, on the other hand, would be very surprised if the runtime cared about those properties at all (and I see no code in runC checking Process.Username
). So whatever we end up doing to clarify the intended behavior, we'll want to cover what happens in situations like that.
let's make a decision on whether this is required for v1.0.0 |
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.
[1]: https://github.com/opencontainers/runtime-spec/pull/680/files#r116554735
|
Otherwise a runtime could silently ignore a property it didn't want to implement, which would be confusing for runtime callers [1]. This closes a potential loophole in the restriction from 766abd6 (runtime.md: Require 'create' to fail if config.json asks for the impossible, 2016-09-08, opencontainers#559). [1]: opencontainers#472 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
Does this mean that everything that cannot be defined for one platform must be moved to platform specific code or explicitly annotated? eg currently |
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].
[1]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc6/config.md#posix-platform-user
[2]: https://github.com/opencontainers/runtime-spec/blob/v1.0.0-rc6/config-linux.md#linux-container-configuration
[3]: https://github.com/wking/opencontainer-runtime-spec/blob/05da00bc76e1746276e977ab45957ab39c31c73a/spec.md#property-specification
[4]: #747 (comment)
[5]: https://github.com/opencontainers/runtime-spec/blame/v1.0.0-rc6/config.md#L162
[6]: https://github.com/opencontainers/runtime-spec/blame/v1.0.0-rc6/config.md#L168-L169
[7]: https://github.com/opencontainers/runtime-spec/blame/v1.0.0-rc6/config.md#L172-L173
[8]: https://github.com/opencontainers/runtime-spec/blame/v1.0.0-rc6/config.md#L176
|
house keeping: |
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.