wking
commented
7 years ago Also tied up in “how do I collect the container exit code?” is “how do I know when the container process has exited?”. An alternative not mentioned in my brief list above would be to poll state and look for a stopped status, and then to read out the container process exit code from a (new) state field (exit-code?). That sounds like a pretty ugly user experience compared to opencontainers/runtime-spec#508, but it's probably the easiest-to-implement way to get over this particular hurdle, and I think it would be better than cutting a spec 1.0 without addressing this issue at all.
I think we're pretty clear that we want a subreaper to collect the container exit code when we're validating runC and other runtimes that use local Linux namespacing/cgroups to implement runtime-spec. However, that approach will not work for runtimes that use VMs, or on Windows, or anywhere that the host cannot see the container process (opencontainers/runtime-spec#459). Do we have a plan for validating those runtimes? Are we going to have a validation approach that ignores the container process exit code and looks for a magic token in the container's stdout? Are we going to adjust the in-flight command line API (opencontainers/runtime-spec#513) to allow for a long-running
create? Are we going to land an event operation (opencontainers/runtime-spec#508)? With a spec 1.0 approaching, we probably want to at least have a strategy for testing these alternative runtimes, even if we don't have all the tooling implemented yet.