connect to http control interface at localhost instead of docker ip

[rade]

Since fastdp landed, the router is running in the host network namespace. This means that the http control interface is on localhost:6783. There is therefore no need to go through contortions in the weave script to obtain the weave container's docker ip. Furthermore, it also means things like weave --local expose will work against a non-dockerized weaver, i.e. the script can invoke IPAM w/o any interactions with docker.

[dpw]

I wouldn't recommend adding dependencies on the fact that the router is running in the host network namespace. fastdp led to that because use of the kernel's openvswitch module strongly suggested that approach. Having it in a netns does seem preferable, and I would not claim that we have exhausted all avenues to achieve that.

[rade]

Having it in a netns does seem preferable, and I would not claim that we have exhausted all avenues to achieve that.

That very much seems like a nice-to-have. There isn't even an issue for it!

If we do ever bother to work on that, and come up with a solution, then we can put the contortions back at that point.

[awh]

At the moment we fall back to running the router in a container netns if WEAVE_NO_FASTDP is defined or if the kernel doesn't have ODP support. Are you suggesting that we run the router in the host netns unconditionally?

[rade]

Are you suggesting that we run the router in the host netns unconditionally?

Yes.

[rade]

If we do this we can get rid of most of the code in proxy.getDNSDomain - we no longer need to inspect the weave container in order to figure out what IP to find the weave control port on.

That code is run for every container created through the proxy, so this is a nice win.