The zone DB no longer considers duplciates of (IP, name); it will
reject duplicates of (IP, name, ident), but this ultimately doesn't
matter since those are all the fields it records anyway.
The HTTP interface treats these duplicates as trivial success (i.e.,
it acts as if it's idempotent, which it is).
This changes the behaviour for removals: if (IP, name) is recorded for
two different containers, removing one will leave the other extant.
These two testing utils assumed that they got an error, and checked
its type; however, the most likely failure case is that there's no
error (i.e., nil). In that case they would cause a NPE panic.
This was rather impenetrable and had some significant code
duplication. So add some words of explanation, and refactor to remove
the duplication.
Some fly-by fixing of minor bug too: buildUnicastRoutes failed to
exclude asymmetric connections from the first hop.
Golang locks aren't re-entrant. As result one can get deadlocks on
RWMutexes like this:
goroutine #1: attempt to acquire read lock -> success
goroutine #2: attempt to acquire write lock -> wait
goroutine #1: attempt to acquire read lock again -> wait
(a pending write lock prevents subsequent acquisitions of read locks)
Peer.HasPathTo could run into this since it could attempt to acquire
the read lock on a peer multiple times if previously it had
encountered that peer via an asymmetric connection.
since w/o that we get an obscure error.
The most likely cause for not having an eth0 is that the docker daemon
has been configured to disable container networking.
e.g. when it was started with --net=none
weavedns wasn't actually using the docker-assigned ip for anything, so
this change is a simple matter of eradicating it from the code.
We want to run as little as possible inside the container netns.
Unfortunately we cannot make that change for the weave container,
since the interface on which we need to invoke ethtool is created by
docker and already inside the container netns by the time we get
control.
Matthias Radestock