@calavera @icecrime @thaJeztah I have temporarily included the engine-api vendoring commit in this PR to help CI succeed. I will rebase this PR once we have an officially vendored in the engine-api dependency. It would be great if we can have the docker/docker side changes & docs reviewed in parallel.

Desgin makes sense to me, LGTM 😉

Originally was thinking links on connect was odd, but I guess it's the only way to actually link to other containers when it's not the primary network....

What's the behavior when on an overlay network and the containers are on separate hosts?

What's the behavior when on an overlay network and the containers are on separate hosts?

@cpuguy83 it will work just as in bridge network. As explained in the proposal, links in non-default networks will be used as aliases and hence it has no static dependencies with the presence of linked container at the time of launch. when the linked container comes up at a later time, the container name will be propagated using the usual Service Discovery mechanisms and the alias is resolved via DNS.

Originally was thinking links on connect was odd, but I guess it's the only way to actually link to other containers when it's not the primary network....

Thats correct. Also it will avoid any confusions between the usage of links in docker run and docker network connect.

to sum up my understanding:
UX is: docker network connect --link containername:localalias ...
and the same docker run --link containername:local alias that would now work on any network, except for the envvar and /etc/hosts behavior that's preserved for backwards compat on the default bridge network.

design +1

@tiborvass 👍

design +1 here as well, moving to code review

@tiborvass @cpuguy83 @vdemeester rebased on top of engine-api v0.2.1.

My only comment is... can we merge TestUserDefinedNetworkLinksWithRestart into TestUserDefinedNetworkLinks?

LGTM

@cpuguy83 i would like to keep them in different test-cases (though some of it are repeating), especially because I would like to treat the restart case as important one to highlight and manage instead of adding multiple important cases in the same test case.

LGTM

Ping @thaJeztah @moxiegirl @SvenDowideit @jamtur01

Alright I briefly discussed with @moxiegirl; we will need a more extensive review on the docs changes that are needed for the "new" --links. Given the code-freeze we can use the time after code-freeze to work on that.

We should probably check all occurrences of --link to see if they need an updated description (both "docs" and "man pages");

So, based on my previous comment, LGTM (for now)

ping @albers new docker network connect --ip --ip6 --link options

when I am using the --link option it still puts the container on the same host as the container it links to as before. how to I use the aliasing across hosts in a way that will allow me to launch my container on another host in swarm and still use the alias. can you specify an example please?

@hackndoes are you creating a network with overlay driver ?
If you are looking for multi-host link capability, you should use multi-host driver such as overlay or other 3rd party plugins.

PTAL : https://docs.docker.com/engine/userguide/networking/get-started-overlay/

@hackndoes it needs to be fixed in swarm: docker-archive/classicswarm#1811

For now you can either disable that filter (but I believe that will also disable volumes_from co-scheduling), or you can use network scoped aliases, instead of link aliases.