Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
command-line-interface: Split create and start
Catch up with be59415 (Split create and start, 2016-04-01, opencontainers#384). I'm not a big fan of this early-exit 'create', which requires platform-specific magic to collect the container process's exit code. I have a proposal for an 'event' operation [1] which would provide a convenient created trigger. With 'event' in place, we don't need the 'create' process exit to serve as that trigger, and could have a long-running 'create' that collects the container process exit code using the portable waitid() family. But the consensus after this week's meeting was to table that while we land docs for the runC API [2]. The "SHOULD exit as quickly as possible after ..." wording is going to be hard to enforce (which is why it's not MUST), but with the runC model, clients rely on the command exits to trigger post-create and post-start activity. The longer the runtime hangs around after completing its action, the laggier those triggers will be. The 'create' ID argument is required (while the old 'start' ID argument was optional) because the runC approach requires an explicit 'delete' call to cleanup the container. With a long-running 'create' that could automatically cleanup, you could have an optional ID to support users that don't care what ID is used (because they know they won't be calling 'state', 'start', etc.). One benefit of the early-exit 'create' is that the exit code does not conflate container process exits with "failed to setup the sandbox" exits. We can take advantage of that and use non-zero 'create' exits to allow stderr writing (so the runtime can log errors while dying without having to successfully connect to syslog or some such). The "MUST NOT attempt to read from its stdin" means a generic caller can safely exec the command with a closed or null stdin, and not have to worry about the command blocking or crashing because of that. The stdout spec for start/delete is more lenient, because runtimes are unlikely to change their behavior because they are unable to write to stdout. If this assumption proves troublesome, we may have to tighten it up later. The ptrace idea is from Mrunal [3]. [1]: opencontainers#508 [2]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2016/opencontainers.2016-07-13-17.03.log.html#l-15 [3]: http://ircbot.wl.linuxfoundation.org/eavesdrop/%23opencontainers/%23opencontainers.2016-07-13.log.html#t2016-07-13T18:58:54
- Loading branch information