One quick hack here would be to run docker attach after we've done the network configuration. But @squaremo pointed out that this will result in any output prior to the attach getting lost.

Looking at the docker API, there's actually no such thing as run. Instead we have create, which starts the container and takes a whole bunch of options regarding attaching to stdin/out/err, and attach, which streams stdin/out/err. I am guessing docker run is implemented in terms of these two.

This suggests that, when the correct options are given to create, output from the container is buffered so it becomes available in a subsequent attach. Therefore, weave could start the container with create, then perform all the network configuration, and then attach.

Can't see how we'd do all that in a shell script though.

I am guessing docker run is implemented in terms of these two [create and attach]

Actually, create doesn't start the container; that is done by start. The sequencing for run is create -> attach -> start. Note that even though the container process isn't started until start, it appears one can attach to the container after create via the API but not the CLI.

We'd have to do something similar in weave, i.e. create, attach and start streaming input/output, start, and then configure container networking.

+1, will make life a whole lot easier for CoreOS / systemd

I'd like to note that there one additional limitation of Docker that comes to play:

--rm=false                 Automatically remove the container when it exits (incompatible with -d)