-
Notifications
You must be signed in to change notification settings - Fork 61
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
Don't hardcode container interface in Docker vmms #76
base: master
Are you sure you want to change the base?
Conversation
|
|
I agree this is a better approach than putting all the constants in the vmms itself. So let's iterate on this idea. The only problem I noticed so far is that on jobs that should timeout, Also, why did you move from Python to Perl? Seems like you had some Python 2 vs 3 compatibility issue? I think most of the developers are more familiar with Python and would like to keep things in Python as much as possible unless there is a very good reason to switch.
|
The python->perl change was a result of what was in the sample container (it only has python 3), assuming that the containers used in production would be similarly minimal, and trying to pick something that would work on both ubuntu and rhel based containers. As the sample Dockerfile is not actually representative, I would certainly be inclined to go back to the python script, as it's easier to read. |
The timeout mismatch happened because there were zombie processes after autodriver did its first kill, and the wrapper, which is pid 1, didn't wait for them. Apparently, when a shell is pid 1, it does end up calling wait() and preventing such zombies from accumulating. I added a background thread to the wrapper which calls wait until autodriver exits (or wait fails). |
the distDocker change has not been tested |
|
|
Instead of putting all the file copying and su-ing in the docker run command constructed by the vmm, include an interface script in the container and use it as the container entrypoint. The only thing passed from the vmm to the container are the resource limit parameters. In addition, rewrite the dockerfile so it (1) includes fewer RUN lines, and (2) does not need to fetch Tango from github in order to build autodriver; Instead, the autodriver source is copied to the container using the ADD instruction
Make the wrapper script compatible with python 2.x (x>=6), not just 3.0
install python2 so interface script can use #!/usr/bin/python Install all of C0's files, and use a wrapper shell script for cc0 so the compiler is always invoked with an absolute path
- spawn a thread that calls wait(). We are pid 1 in the container and need to collect all zombies, otherwise autodriver might get confused - Don't double fork. it's not easy to pass the full exit status of autodriver through a double fork, so use os.execvp instead of subprocess.call. This means we have to do some of the file descriptor munging directly. - Don't bother creating a temporary output file. Directly pipe autodriver's output to the real output file
master now has 2 dockerfiles, one targeting 122 with C0, and one not Apply updates (fewer RUN lines, do not fetch autodriver from github) to both of them.
This cleans up some warnings
bdb6a5e
to
1d72166
Compare
Instead of putting all the file copying and su-ing in the docker run
command constructed by the vmm, include an interface script in the
container and use it as the container entrypoint. The only thing
passed from the vmm to the container are the resource limit parameters.
The script interface might be changed to pass in the volume name and/or the name of the output file so the script doesn't even to know that.
In addition, rewrite the dockerfile so it (1) includes fewer RUN lines, and
(2) does not need to fetch Tango from github in order to build autodriver;
Instead, the autodriver source is copied to the container using the ADD
instruction