make it easier to run weave (including fastdp) dockerless

[rade]

This came up on IRC...

Some users want to run the weave router in a docker-less environment, e.g.

• as an entry/exit point into a weave network
• in order to create a VPN between several hosts

This was never a use case we took much care in supporting, but actually was possible without too much difficulty by

1. building the weave router with make prog/weaver/weaver
2. creating a bridge with weave --local create-bridge
3. launching the router as prog/weaver/weaver --iface=weave --no-dns
4. giving the weave bridge an IP address on the target weave network with ip addr add dev weave <cidr>

The last step is a bit awkward, since really you'll want to get an address from IPAM. And really we just want weave --local expose to work. #1546 will help here.

The introduction of fastdp has broken step 2 unless the user disables fastdp. But we really want them to be able to use fastdp in this setup. @dpw @awh any suggestions? What problems are there besides the packaging issue (i.e. the fact the weave script invokes docker in order to run weaver in order to create the fastdp bridge)?

[dpw]

2 becomes weaver --create-datapath --datapath=weave 3 becomes weaver --datapath=weave --no-dns

(3 also needs --name=$(cat /sys/class/net/weave/address), but it did for you too.)

[dpw]

but it did for you too

Ah, not true - weaver will take --name from the --iface netdev MAC. It would be trivial to do that for the --datapath argument too, of course. But as the weave script always passes --name, I didn't see a reason for that.

[rade]

2 becomes weaver --create-datapath --datapath=weave

but create_bridge does a bunch of extra stuff, at least some of which seems relevant in a docker-less context, e.g. setting the MTU, creating an iptables rule for traffic across the bridge, marking the bridge as 'up', configuring the arp_cache.

[dpw]

Sure, but all of that could be considered "nice to haves", just like the iptables rules and unsolicited arp that weave expose does and step 4 misses out on. (Did IPAM "break" this use case too?)

If we want to support this use case, then by all means let's support it. Fastdp presents no real obstacles.

[rade]

"nice to haves" ... step 4 misses out

which is why I said "really we just want weave --local expose to work. #1546 will help here."

Fastdp presents no real obstacles.

Good to know. It has made things more fiddly though, which seems relatively easy to fix, so we should do that.

Ultimately, I reckon we should aim to get something like WEAVE_NO_DOCKER=1 weave ... to work for most weave commands:

• --help | help, version
• launch (launches "everything", which in this mode is just the router)
• launch-router (launches in foreground)
• connect, forget
• status, report
• dns-add, dns-remove, dns-lookup
• expose, hide
• reset
• rmpeer

[errordeveloper]

An additional use-cases for this are Mesos (some installations of), rkt and lxd.

[bboreham]

Just to note that weave-kube runs without reference to Docker; it uses both weave --local create-bridge and weave --local expose.

We still do not offer any packaging other than as a Docker image.

[bboreham]

Although I think create-bridge will still fail if there is no bridge named docker0