Skip to content

Commit 72e8062

Browse files
committed
runtime: Explicitly make process.* timing implementation-defined
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]: #620 (comment) Signed-off-by: W. Trevor King <[email protected]>
1 parent be3a184 commit 72e8062

File tree

1 file changed

+6
-3
lines changed

1 file changed

+6
-3
lines changed

runtime.md

Lines changed: 6 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -100,9 +100,12 @@ This operation MUST return the state of a container as specified in the [State](
100100

101101
This operation MUST [generate an error](#errors) if it is not provided a path to the bundle and the container ID to associate with the container.
102102
If the ID provided is not unique across all containers within the scope of the runtime, or is not valid in any other way, the implementation MUST [generate an error](#errors) and a new container MUST NOT be created.
103-
Using the data in [`config.json`](config.md), this operation MUST create a new container.
104-
This means that all of the resources associated with the container MUST be created, however, the user-specified program MUST NOT be run at this time.
105-
If the runtime cannot create the container as specified in [`config.json`](config.md), it MUST [generate an error](#errors) and a new container MUST NOT be created.
103+
This operation MUST create a new container.
104+
105+
All of the properties configured in [`config.json`](config.md) except for [`process`](config.md#process) MUST be applied.
106+
[`process.args`](config.md#process) MUST NOT be applied until triggered by the [`start`](#start) operation.
107+
The remaining `process` properties MAY be applied by this operation.
108+
If the runtime cannot apply a property as specified in the [configuration](config.md), it MUST [generate an error](#errors) and a new container MUST NOT be created.
106109

107110
The runtime MAY validate `config.json` against this spec, either generically or with respect to the local system capabilities, before creating the container ([step 2](#lifecycle)).
108111
Runtime callers who are interested in pre-create validation can run [bundle-validation tools](implementations.md#testing--tools) before invoking the create operation.

0 commit comments

Comments
 (0)