#weavenetwork

squaremo: ah, irc is actually working here...

how's the snow?

bryanb: it's a lot of it

we will be going out to the woods in the evening

with torches

(not the ones with batteries, but proper ones)

errordeveloper: are you here mate?

yaronr: maybe someone else can help you?

:)

I'm trying to figure out the best way to use weave+dns on a container that has --net=host.

I've already 'exported' weave on the host, but DNS is a bit more complicated

(host is CoreOS Btw)

ah, so without the Docker bridge, your container won't be able to talk to weavedns?

I need resolv.conf to use weavedns, but also another DNS for robustness / failure zones

well, not necessarily

weavedns should fall back to what it sees in its resolv.conf

I've exported weave on the host, so IP wise I can reach any weave ip

the problem is what if weavedns is down.

I need two 'nameserver' entries on the host

one of them would be the docker bridge

the other would be 8.8.8.8 or something

not 100% sure that works, though

(the problem with only putting the weavedns as the DNS for the host, is that when the host boots for the first time and tries to download docker images, it looks for the docker repository. it does a DNS lookup. There's no weave yet. so lookup would fail)

in the words of someone wiser than myself, "multiple nameserver lines in resolv.conf doesn't necessarily work the way you want it to".

yeah, I was wondering about that. I got some conflicting answers

what do you think?

Can you do it so (a) processes outside Docker don't know anything about weavedns, (b) (some) containers are pointed solely at weavedns and (c) weavedns has fall-back to 8.8.8.8 ?

Note that The weave script always sets the weavedns address as the Docker bridge IP - not an address on the weave network.

but that IP should be reachable from a container with --net=host, because it is an IP on the host

I can foresee a potential problem, which is that weaveDNS will look for its fallback in resolv.conf, and find itself.

I did a quick test, and I get "Conflicting options: --net=host can't be used with --dns" from Docker

ah, ok that too ..

Looks like Docker copies the resolv.conf entries from the host when --net=host is in use

So now I think I understand yaronr's question.

sorry guys I was on another context. let me read :)

it is possible to rewrite resolv.conf from inside a container, so you could run your container with --net=host, insert the weavedns IP (docker bridge IP) at the top of the file, then run the real program

btw does it copy resolv.conf, or bind mount to it?

I believe Docker copies the entries, writing a new file

but that's from a vague memory of reading the Docker source.

btw2: the reason for all of this is mesos. mesos slaves need to have split personalities - on one hand, be accessible to the masters (which in my case means weave netowrk), but on the other - when they run containers, these containers need to have the host's network

https://docs.docker.com/articles/networking/#co... tells you how resolv.conf is created

but in a broader scope - if weave could be more than just the docker network, but a general purpose overlay network - that would be great. export is taking it really close

I don't know much about Mesos, but https://issues.apache.org/jira/browse/MESOS-1621 suggests that the need for --net=host has gone away?

bryanb: that depends. There's two options for how to run mesos tasks, if running mesos slaves as docker: docker-in-docker (mesos tasks are docker containers 'inside' the mesos slave docker), or on the docker host

The first option adds a lot of complexities, and probably requires --net=host. The second option apparently doesn't require --net-host, but in reality it does - because not everything is containerized as docker..

so if I'm using the mesos containerizer, it would run a process inside the mesos-slave docker. how will I access this container?

maybe weave can help here as well, since the mesos slave is ON the weave network.. I need to think about it

everything is Meta these days :)

sorry, I don't know enough about Mesos to answer that.

Back to my original question, then.

My answer is to leave resolv.conf alone on the host, and rewrite it inside the containers that need to see weavedns.

this is just a hack work-around for Docker not allowing --net=host and --dns at the same time. I don't understand why they have that restriction.

I decided to ask about that last point in #docker.

I got a nicer version of the work-around: put 'nameserver [weavedns-ip]' in a file, then mount it into your containers via '-v thisfile:/etc/resolv.conf'

which I just tested and seems to work ok

I raised the question of --net=host vs --dns at https://github.com/docker/docker/issues/10384

bryanb: thanks! I'll give it a try. let me know if the docker guys come back with anything remarkable

hello

I'm having troubles building weave

djx: yes?

moonfish on fedora 64 bits

do you get an error?

/bin/ld: cannot find -lpcap

/bin/ld: cannot find -lpthread

/bin/ld: cannot find -lc

and, btw, why are you building weave?

the odd part is that I've installed libpcap

moonfish: I'm from noironetworks

good, though that doesn't answer my question ;)

did you install libpcap-*dev*?

lol sorry, I'm building it to try it, hack it and break it

yep, both 64 and 32

hah!

presumably you have seen http://zettio.github.io/weave/building.html

yep

pcap aside, not finding libc and libpthread is a bit more of a worry.

moonfish: who provides libpthread? libevent, right?

I haven't got the faintest idea.

I have the libpthread provider installed

whatever that is. I am not familiar with fedora terminology.

have you managed to build anything else on that machine?

I built socketplane

and docker

so, wild guess, you don't have the static libs installed.

moonfish 2 problems fixed, 1 to go

lol

make

go get -tags netgo ./weaver