270_use_name_as_hostname_test fails on Docker 1.11.0-rc4

[rade]

tested with Weave 1.4.6 and 1.4 head.

Use container name as hostname
4b283802ed4ad8637083883e3e3f591a1e913068f95ba446cfebe48119830845
78b26a5b280af7329bb290811d7af521927fce3bdef4252fe5e35d01e9c9d87f
6d3acabc8d9f5a18a4f879fa09fb7f1abc0b1f7a765fc57b3ec67cd2a77fce79
32ccb6dee06b6f710af33d37bf6b6619624b08475724ef1f0526b2f7a24b296a
d97ecd4b3ee35d39b1c7debca8b43355fee7063f7bf6d23f4e995fd20f27f333
fea9d21472c72f721540d326510da47c1c1c6f4a900f4e2ad53565359ddd2276
1a9b9e7a2b668a038aa3fb2380432d6ed36c4442c9120f3a06002a678d2df23a
3edb9579a2a02c48f42c5e574193ab665f72a573d458d0769640115a8323e67d
test #1 "docker_inspect_fqdn 192.168.48.11 c1" failed:
    expected "c1.weave.local"
    got "c1.weave.local."
test #2 "docker_inspect_fqdn 192.168.48.11 c1" failed:
    expected "c1.weave.local"
    got "c1.weave.local."
test #3 "docker_inspect_fqdn 192.168.48.11 c1" failed:
    expected "c1-hostname.weave.local"
    got "c1-hostname.weave.local."
test #4 "docker_inspect_fqdn 192.168.48.11 c1" failed:
    expected "c1-hostname.weave.local"
    got "c1-hostname.weave.local."
test #5 "docker_inspect_fqdn 192.168.48.11 c1" failed:
    expected "c1-hostname.weave.local"
    got "c1-hostname.weave.local."
test #6 "docker_inspect_fqdn 192.168.48.11 c1" failed:
    expected "c1-hostname.weave.local"
    got "c1-hostname.weave.local."
test #7 "docker_inspect_fqdn 192.168.48.11 c1" failed:
    expected "c1-hostname.weave.local"
    got "c1-hostname.weave.local."
test #8 "docker_inspect_fqdn 192.168.48.11 c1" failed:
    expected "c1-hostname.weave.local"
    got "c1-hostname.weave.local."
8 of 9 tests failed in 15.648s.

The reason is that the {{.Config.Domainname}} in

    docker_on $1 inspect --format='{{.Config.Hostname}}.{{.Config.Domainname}}' $2

now contains a trailing dot, presumably due to moby/moby#20200.

I am hoping that this is just a problem with the test and that the weave code itself is fine. We do inspect the domain name in a few places, so need to check those carefully for any possible problems not caught by the tests.

[brb]

Small correction: we get the trailing dot, because .Config.Domainname is empty and the format syntax contains the dot separator.

[rade]

Are you sure?

$ ./weave1.4.6 launch
$ docker $(./weave1.4.6 config) run --name=boo -dti alpine /bin/sh
$ docker inspect --format='{{.Config.Domainname}}' boo
weave.local
vagrant@host1:~$ docker inspect --format='{{.Config.Hostname}}' boo
boo

(Though this doesn't show a trailing dot either)

[brb]

Interesting. I'm starting a container with weave run (as it is done in the test):

$ ./weave run --name=c2 -t alpine /bin/sh
81c8bb64a812134e25ef41e6a322bb4f080c03a430f1bc5e92b35d0ad1d05f5e
$ docker inspect --format={{.Config.Domainname}} c2

$ docker inspect --format={{.Config.Hostname}} c2
c2.weave.local
$ ./weave run --name=c3 -h c3-hostname.weave.local -t alpine /bin/sh
7dd6922a4024134399aef9fcd650115853fe1f77eb2b05630b9cb948ef324c48
$ docker inspect --format={{.Config.Hostname}} c3
c3-hostname.weave.local
$ docker inspect --format={{.Config.Domainname}} c3

However, when I start with docker run, I get the same output as you.

[brb]

To recap, the problem is that moby/moby#20200 removes splitting of hostname (https://github.com/docker/docker/pull/20200/files#diff-555969c76e0ae264bc1e3c8e880cb50cL247) into hostname and domainname from the docker daemon, thusdomainname can only be set explicitly.

When we start a container with weave run, internally, we use docker cli which does not allow us to pass domainname, thus the .Config.Domainname field is empty. However, when we start a container by using docker $(weave config) run (i.e. via weaveproxy), we rely on docker api which, in opposite to the cli, supports the domainname field. Therefore, in this case you can see that .Config.Domainname is properly set.

After inspecting the weave codebase and checking the output of hostname and dnsdomainname run on the containers, I can say that it should not cause us any serious issues besides the inconsistency mentioned above. Therefore, one suggestion would be:

• Fix the failing tests by removing the trailing dots from the inspect output.
• Propose to extend docker cli in order to support -domainname flag which could fix the inconsistency.

Thoughts?