Merge weaveDNS with router

[rade]

Overview

We should produce a single executable and image containing the router + weaveDNS. This simplifies the UI and also lays the foundation for re-architecting weaveDNS to use the router's gossip.

User visible changes:

• weave launch-dns goes and instead we have a --dns <cidr> (name TBD) option to weave launch
• weave stop-dns goes
• weave version will no longer report on the weavedns image
• weave status output might look a little bit different

The main tricky bit is that the weave container currently does not have an IP address on ethwe, and only performs capture/inject on the interface. Would adding the IP+network for weaveDNS break capture/inject? And would the router correctly capture/inject packets from/to the local weaveDNS?

Worst case we could add a separate interface for the capture/inject.

Implementation Phases

This feature should be delivered as four incremental PRs:

1. make weave launch launch everything #962 Make weave launch launch everything
2. Relocate weaveDNS executable inside router image #841 Relocate weaveDNS executable inside router image
3. Perform router capture/injection on a separate dedicated interface #842 Perform router capture/injection on a separate dedicated interface
4. Merge weaveDNS executable into router executable #843 Merge weaveDNS executable into router executable

[dpw]

Would adding the IP+network for weaveDNS break capture/inject? And would the router correctly capture/inject packets from/to the local weaveDNS?

I don't think the IP itself poses a problem. But I suspect that any packets produced by the router container on ethwe by any means will not be captured by the router, due to our attempts to avoid the router capturing packets that it injects. We might be able to work around this with a more complicated pcap filter, but it would an ugly coupling between very separate concerns. So we might want to give the router container a separate ethwedns interface.

Note that when using ODP, the router does not need an ethwe at all: Its interactions are directly with the datapath via netlink. That does not prevent the use of an ethwe though.

[rade]

So we might want to give the router container a separate ethwedns interface.

I was suggesting giving the router a separate interface from ethwe, e.g. ethwecap, since it's the router interface that is special (i.e. it's used for capture/inject, and has no IP).

[squaremo]

weave launch-dns goes and instead we have a --dns (name TBD) option to weave launch

The user (still) shouldn't have to care what the weave IP of the DNS server is. Can't it get it with the IPAM system?

[rade]

Can't it get it with the IPAM system?

See #762 and #763.

[bboreham]

And would the router correctly capture/inject packets from/to the local weaveDNS?

I don't see why the router would want to get involved in packets between local containers and local weaveDNS.

I do think there is a tricky question of routing - would weaveDNS have an IP address in every subnet used by local containers? Or would every local container be given an additional IP address on a weaveDNS subnet?

[rade]

I don't see why the router would want to get involved in packets between local containers and local weaveDNS.

It doesn't. The issue is communication between the local DNS and its peers.

I do think there is a tricky question of routing

We are not planning to change anything in how containers talk to DNS.

[bboreham]

Sorry, I was conflating this issue with the idea of having just one network (i.e. no Docker bridge)

[rade]

things that can be done as separate PRs

1. remove weave launch-dns and weave stop-dns; add --dns <cidr> option to weave launch. Requires changes to script, tests, docs.
2. move weavedns executable into weave image; get rid of weavedns image. start weavedns by specifying distinct entrypoint. Requires changes to script, makefile, Dockerfiles, and some docs.
3. make router capture/inject on a differently named interface. Requires changes to script.

things we need to do to merge the weavedns executable into weaver:

1. merge weavedns main into weaver main
   • prefix all dns options with 'dns-'
   • merge signal handlers
   • merge http handlers (at least make sure they don't trip over each other)
   • merge status output
   • merge log configuration
   • merge docker event listeners (at least make sure they don't trip over each other)
2. make sure log entries from router and dns can be distinguished
3. script changes
   • configure an ethwe, in the normal way, on weave container, if --dns <cidr> is specified
   • don't launch a separate container when --dns is specified; pass a flag to the weave container start instead that enables dns.

[rade]

For backward compatibility, weave [start|stop]-dns should write a warning stderr and exit successfully.

[tomwilkie]

This has been superseded by #826