runtime: Explicitly make process.* timing implementation-defined #700
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
wking
added a commit
to wking/opencontainer-runtime-spec
that referenced
this pull request
Feb 27, 2017
Since be59415 (Split create and start, 2016-04-01, opencontainers#384), it's possible for a container process to never execute user-specified code (e.g. you can call 'create', 'kill', 'delete' without calling 'start'). For folks who expect to do that, there's no reason to define process.args. The only other process property required for all platforms is 'cwd', but the runtime's idler code isn't specified in sufficient detail for the configuration author to have an opinion about what its working directory should be. On Linux and Solaris, 'user' is also required for 'uid' and 'gid'. My preferred approach here is to make those optional and define defaults [1,2]: If unset, the runtime will not attempt to manipulate the user ID (e.g. not calling setuid(2) or similar). But the maintainer consensus is that they want those to be explicitly required properties [3,4,5]. With the current spec, one option could be to make process optional (with the idler's working directory unspecified) for OSes besides Linux and Solaris. On Windows, username is optional, but that was likely accidental [6]. So an unspecified 'process' would leave process.cwd and process.user unset. What that means for the implementation-defined container process between 'create' and 'start' is unclear, but clarifying how that is handled is a separate issue [7] independent of whether 'process' is optional or not. [1]: opencontainers#417 (comment) [2]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/DWdystx5X3A Subject: Exposing platform defaults Date: Thu, 14 Jan 2016 15:36:26 -0800 Message-ID: <20160114233625.GN6362@odin.tremily.us> [3]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2016/opencontainers.2016-05-04-17.00.log.html#l-44 [4]: opencontainers#417 (comment) [5]: opencontainers#417 (comment) [6]: opencontainers#618 (comment) [7]: opencontainers#700 Signed-off-by: W. Trevor King <wking@tremily.us>
wking
force-pushed
the
process-config-timing
branch
2 times, most recently
from
15f89da
to
61afca0
Compare
|
rebase plz :) |
Based on IRC discussion today (times in PST) [1]:
11:36 < crosbymichael> just take a step back and think about it.
you have a process object in the spec. its a single object
defining what to run. How do you run a process? you exec its
args. From the spec pov its an atomic operation. in between
create and start its not running the users code and is left up to
the runtime. you either have a process defined by the spec and
its created as an operation in the container on start or your
dont.
With the previous wording, it was unclear how large a hole we were
poking with "the user-specified program MUST NOT be run at this time".
This commit removes that ambiguous wording and replaces it with an
explicit reference to 'process.args'. It makes it clear that
everything outside of 'process' MUST happen at create-time. And it
leaves all of 'process' except for 'process.args' up to the
implementation.
This means that the caller has no reliable way to set the
user/cwd/capabilities/… of the runtime's container process between
'create' and 'start'. You could avoid that limitation by requiring
all process properties *except* process.args be applied at
create-time, but my attempt to make process.args optional (which would
have allowed that interpretation without burdening callers who never
intended to call 'start') was rejected in favor of this all-or-nothing
approach to 'process' handling [2].
[1]: http://ircbot.wl.linuxfoundation.org/eavesdrop/%23opencontainers/%23opencontainers.2017-02-27.log.html#t2017-02-27T19:35:35
[2]: opencontainers#620 (comment)
Signed-off-by: W. Trevor King <wking@tremily.us>
wking
force-pushed
the
process-config-timing
branch
from
61afca0
to
72e8062
Compare
|
LGTM |
1 similar comment
|
LGTM |
Merged
wking
added a commit
to wking/opencontainer-runtime-spec
that referenced
this pull request
Oct 4, 2017
In 718f9f3 (minor narrative cleanup regarding config compatibility, 2017-01-30, opencontainers#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, opencontainers#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, opencontainers#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, opencontainers#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. With this line removed, consumers will be able to rely on valid-value support in compliant runtimes, although many properties could use clearer runtimes-MUST-support wording for those values. However, we can sort those out on a per-property basis. 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]: opencontainers#813 (comment) [2]: opencontainers#673 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainer-runtime-spec
that referenced
this pull request
Oct 4, 2017
In 718f9f3 (minor narrative cleanup regarding config compatibility, 2017-01-30, opencontainers#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, opencontainers#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, opencontainers#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, opencontainers#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. With this commit, consumers will be able to rely on valid-value support in compliant runtimes. 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]: opencontainers#813 (comment) [2]: opencontainers#673 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainer-runtime-spec
that referenced
this pull request
Oct 4, 2017
In 718f9f3 (minor narrative cleanup regarding config compatibility, 2017-01-30, opencontainers#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, opencontainers#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, opencontainers#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, opencontainers#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]: opencontainers#813 (comment) [2]: opencontainers#673 (comment) Signed-off-by: W. Trevor King <wking@tremily.us>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Based on IRC discussion today:
This means that the caller has no way to set the user/cwd/capabilities/… of the runtime's container process between
createandstart. You could avoid that limitation by requiring all process properties exceptprocess.argsbe applied at create-time, but my attempt to makeprocess.argsoptional (which would have allowed that interpretation without burdening callers who never intended to callstart) was rejected in favor of this all-or-nothing approach toprocesshandling.