Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Collect container exit codes across platforms #305

Open
wking opened this issue Jan 12, 2017 · 1 comment
Open

Collect container exit codes across platforms #305

wking opened this issue Jan 12, 2017 · 1 comment

Comments

@wking
Copy link
Contributor

wking commented Jan 12, 2017

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.

@wking
Copy link
Contributor Author

wking commented Jan 12, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant