You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.The text was updated successfully, but these errors were encountered: