I considered a couple of different factorings, that is
* Implementing the fallback as a Lookup
* Having a server struct that held the resolv.conf and methods for
handling queries
but ultimately, this is simple and works.
* Put prefixes (including msg IDs) in front of log messages to
distinguish them
* Failed lookups get logged under Info as per issue #311
* More accurate messages as per issue #311
So as not to pollute command-line flags with test.* options.
It appears that importing "testing" (from stdlib) will add flags. To
avoid this, we need code to not depend on testing. But, since
testing_utils was previously in the same package as the rest of the
code, it dragged testing in.
Renaming testing_util.go to e.g., util_for_test.go might be enough to
avoid it being compiled with the regular code. We may want it to be
available to tests for other packages -- after all it is utilities for
testing -- so it goes in its own package.
NB I removed free variables from the LookupFunc implementations, to
avoid confusion between `s` the receiver and the closed-over `s`.
Also corrected a mistake in the write error log message.
This separates Zone into the DB ops and the Lookup ops, and implements
the latter for MDNSClient so it can be used just like the zonedb.
A notable change is that Lookup methods only ever return one result,
while MDNSClient.SendQuery could in theory return multiple results
(though it wouldn't, because no server would supply more than one
result in a response, and it stops waiting after getting one response
..).
ReverseLookupLocal is implemented even though no MDNSServer will
answer at present (hence no test yet).
Lastly, the handler (creating) functions can now be given a list of
Lookup implementations to try in order.
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.
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.
Michael Bridgen