Implement docker detach/reattach test about autotest-docker

[ldoktor]

a=aexpect.ShellSession("TERM=xterm bash")
a.sendline("docker run -t -i fedora bash")
a.sendline('\x10\x11')
print a.read_nonblocking()
a.sendline("echo $HOSTNAME")
print a.read_nonblocking()

doesn't work either. (still inside the docker). There is an odor of decay in the kingdom of python/docker.

[ldoktor]

Another update, I'm still unable to interact properly with docker, but I tested ctrl+a d to detach from screen, and then screen -x to attach back. When the session is screen the process dies (which makes sense), but when I use aexpect.ShellSession("TERM=xterm bash") and then execute screen -x, ctrl+a d I'm back in the original bash and can again attach by screen -x.

So it should be possible, just docker handles the ctrl-sequences differently.

[ldoktor]

Ha, apparently python was just too quick. This works:

a=aexpect.ShellSession("TERM=xterm bash")
a.sendline("docker run -t -i fedora bash")
time.sleep(1)
a.sendline("echo $HOSTNAME")
print a.read_nonblocking()
a.send('\x10')
time.sleep(1)
a.send('\x11')
time.sleep(1)
a.sendline("echo $HOSTNAME")
print a.read_nonblocking()

So I can take care of this test...

[ldoktor]

The time.sleep() is not needed. Only the ctrl+p and ctrl+q has to be sent in separate command:
a.send('\x10\x11') - does not work
a.send('\x10'); a.send('\x11') - works fine
Which is funny, because screen understands booth versions...

[cevich]

@ldoktor Since we don't really care about testing kernels, and specific shell tty/pty layers, I think you'll need to take a more direct approach: pty.fork() + pty.spawn() (in the child) https://docs.python.org/release/2.6.8/library/pty.html#module-pty

Alternatively, you could use os.openpty() and subprocess.popen (with shell=False). Either way, you'll then be able to use the tty and termios modules to setup and exercise exactly the aspects you want to test. Otherwise there's a billion uncontrolled middle-layers that will lead to a very environment and hardware-dependant test.

Make no mistake, this is complicated stuff, however you probably only need to figure it out once 😄 For some hints, check out docker's own CLI and integration tests. There are a few which take the approach I mentioned above, and could provide some hints on how to do it in python.

[cevich]

@ldoktor is this issue still relevant? IIRC I saw these included in a test somewhere, I could be wrong though.

[ldoktor]

Hi Chris, yes, this test still doesn't exist (only in dexpect demonstration). But once we include dexpect, I'll develop this test instantaneously. 😄

[cevich]

@ldoktor Oh right, thanks for the reminder, that's where I saw the code. Okay, bumping out to 0.7.5 then.

[cevich]

@ldoktor Can this test be done to incorporate dexpect in the subtest module so it doesn't create dependencies on the dockertest API, and gives us way to demo/tweak dexpect before moving it into the core?

[cevich]

Better-yet, stick only the bare-minimum needed to get this test written simply and cleanly. It's more important we test this feature now than test it much later in possibly a more abstract way. In other words, keep code reuse problems confined to the scope of this test, don't worry about how other future tests could reuse something.

[cevich]

Moving to "future version" to follow pull-requests, then get moved into the 0.8.x series somewhere when ready.

[cevich]

(3) (CI) Test docker console detach/attach