weave launch-dns fails if IPAM allocation blocks

[awh]

Observe:

$ ./weave launch -initpeercount 2
d9fd4b2eb9af2b0b5e5a5a22853b42fabcf4f2bee525df0c934123a073e3c0ec
$ time ./weave launch-dns
Container 9d01006caae41717fc5924df4edc725fd5573ab6abddf66e03b7b6bc172541e8 not running.

real    0m20.726s
user    0m0.014s
sys 0m0.005s
$ echo $?
1

This also affects the new launch everything behaviour (#962):

$ time ./weave launch -initpeercount 2
Container 6734b7dac75dc7c6800d0f212b81351315afd427958f37c0569bf575b34048ec not running.

real    0m22.109s
user    0m0.008s
sys 0m0.003s
$ echo $?
1
$ docker ps
CONTAINER ID        IMAGE                     COMMAND                CREATED             STATUS              PORTS                                            NAMES
09699147a938        weaveworks/weave:latest   "/home/weave/weaver    3 minutes ago       Up 3 minutes        0.0.0.0:6783->6783/tcp, 0.0.0.0:6783->6783/udp   weave 

These semantics aren't particularly helpful - the weaveDNS launch part should either block indefinitely, or succeed immediately and wait for the allocation to complete in the background.

[rade]

the weaveDNS launch part should either block indefinitely, or succeed immediately and wait for the allocation to complete in the background.

What's special about weaveDNS here? i.e. why wouldn't the same apply to starting application containers?

[bboreham]

I guess the point is we ought to get our own containers to behave satisfactorily, then that can be a model for application containers.

[rade]

Let's just wait forever everywhere then.

[rade]

...and get weavewait / EnsureInterface to log when that happens. Though only after a few seconds, i.e. if the interface comes up "quickly" then don't log anything.

[bboreham]

Also related: #700 and #666

[squaremo]

The solution in #1064 is to have --wait -1 mean "wait forever for the ethwe interface", and to make that the default. There's two problems:

Firstly, the user will have little idea what's going on; because nothing is output while waiting, there's no indication what the problem is. It'll be pretty easy to end up waiting for something that won't happen without further intervention; i.e., to effectively deadlock yourself.

Secondly, if this becomes unnecessary (say if the weaveDNS process doesn't need a weave IP after all), the value -1 may still be hardwired into scripts, so it has to retain a meaning. Possibly this is harmless -- if there's never any need to wait, any value will do.