🍻

+1 for allowing multiple --net

+1

@coolljt0725 thanks. the reason that we didn't support multiple --net is the limitation with our current UX/API to support grouping options together. For example, how would one go about deciding which expose / port-mapping rules map to which network ? I will review the design / code and provide more feedback.

@mavenugo That's what I concern about too. The design should be updated when I back from Barcelona, I'm about to have a trip to Barcelona and attend the Dockercon, so doesn't get much time to update this the next few days.

ping @mavenugo did you have time already to look at the design? Or is this something we cannot implement, because of the issues you mentioned?

@thaJeztah @coolljt0725 If we have to support multiple --net, we must also consider all the network specific options such as --mac-address (also we have upcoming options such as ip, alias, etc.). Also, options such as -p, -P, --expose needs some additional treatment with the current back-end implementation. @aboch was working towards moving the port-mapping from endpoint specific configuration to a sandbox specific configuration and it has interesting cases when it comes to multiple networks.
One way to support it is to namespace all these options with an optional <network>: prefix. something like --mac-address=net1:00:02:04:00:00:01. That obviously is going to cause interesting parsing logic issues :) especially for options such as--ipv6. Hence before implementing multiple--net`, lets try and find a way to fix this.

An alternate option is to approach it from the requirement standpoint. The only obvious reason I could think of for multiple --net is for the ability for the container to be attached to multiple networks before the container starts. Hence, if we let the user docker create a container attached to a single network (as today) and allow the user to use docker network connect to connect the created container to a network & followed by a docker start which will actually start the container attached to multiple networks as it comes up. This option provides a way for the user to get what they want without the UX complexities. WDYT ?

@thaJeztah @mavenugo For the UX, what about add a @net suffix, something like this --mac-address=00:02:04:00:00:01@net1? this would not case parsing logic issues.
I personally don't like the second approach, it's a way to but docker network connect doesn't support configuraion

@coolljt0725 Upon further deliberation and discussions with @aboch & @mrjana, we felt either of the solutions can work and can be implemented independently to achieve the same effect. But I prefer option #2 as the primary way to solve the problem as it makes the configuration simpler and not add any parsing logic or educate the users for a new way of configuring parameters.

We have to anyways add these options to docker network connect and I also think it makes the UX simpler and easy to use.

So, my vote is for option #2. @mrjana @aboch WDYT ?

@mavenugo make sense. They are actually independent implementation

Second option sounds good to me too (i.e., being able to connect a created/stopped container to a network)

ping @mrjana do you agree?

I think we should close this one then, because the current implementation won't work because it doesn't support setting options for multiple networks.

@thaJeztah 👍

Thanks @mrjana I'll close this PR then.

@coolljt0725 Are you interested in implementing the proposed change, or do you want someone else to work on that?

@thaJeztah implement the second proposal need the PR #18531 to be merged.

@coolljt0725 Thanks for your patience. #18531 is merged now. Just to confirm, will you be working on option #2 ?

@mavenugo I working on the option 2. :)

+1

This is something we are also looking for

+1

@alex-berger @mannarra @skairali Please refer here : #17796 (comment), specifically -

"An alternate option is to approach it from the requirement standpoint. The only obvious reason I could think of for multiple --net is for the ability for the container to be attached to multiple networks before the container starts. Hence, if we let the user docker create a container attached to a single network (as today) and allow the user to use docker network connect to connect the created container to a network & followed by a docker start which will actually start the container attached to multiple networks as it comes up. This option provides a way for the user to get what they want without the UX complexities."

and #18906 where this is implemented.

With this PR, there is no need to have multiple --net in docker run. Instead one can create a container in a network and connect to more networks using docker network connect. followed by docker start {container}. With this, you can get the same functionality desired as supporting multiple --net in docker run.

@mavenugo This makes sense. This would solve many usecases for us. So for clarity I would assume that if we use #18906 - would the sequence of operations be like

a) Create container with single network ( Container not yet started)
b) Attach all networks required using network connect ( Container not yet started)
c) Start the container ( it comes up with all networks attached)

If above is the sequence - I would say, it would handle most of the cases as you mentioned

One more trivial question - #18906 - Can we patch this on top of 1.9 ( We have 1.9 running now) or its dependent on any 1.10 stuff?

@skairali The sequence you described is correct :)

The workaround suggested works well except that I am not able to control the interface names when docker connects to multiple networks. Only the first network specified in the docker create command is assigned an interface eth0. Subsequent networks get connected to the container in random order (random eth interfaces)

Is there a workaround to specify the name of the interface in docker network connect command like the -i flag used in the pipework script?

Steps to re- create the issue :

docker network create --driver bridge --subnet 10.100.1.0/24 net1
docker network create --driver bridge --subnet 10.100.2.0/24 net2
docker network create --driver bridge --subnet 10.100.3.0/24 net3
docker network create --driver bridge --subnet 10.100.4.0/24 net4
docker create -it --net=net1 --ip=10.100.1.3 --name=test centos:7
docker network connect --ip 10.100.2.3 net2 test
docker network connect --ip 10.100.3.3 net3 test
docker network connect --ip 10.100.4.3 net4 test
docker start test
docker exec -it test yum install -y net-tools
docker exec -it test ifconfig

I observed that eth2 was assigned 10.100.4.3 and eth3 was assigned 10.100.3.3. This behavior is not consistent. During some runs the interfaces are assigned in order (eth2 - 10.100.3.3 and eth3 - 10.100.4.3 ).

@satyajitbm could you open a new issue / feature request for that?

Attaching a container to multiple networks and then starting it is failing if one of the networks is of type ipvlan.

docker network create --driver bridge --subnet 10.100.1.0/24 net1
docker network create -d ipvlan --subnet=1.1.1.0/24 -o ipvlan_mode=l3 -o parent=eth0 ipvlannet1
docker create -it --net=net1 --ip=10.100.1.3 --name=test alpine sh
docker network connect --ip 35.185.254.1 ipvlannet1 test
docker start test

Error response from daemon: oci runtime error: container_linux.go:262: starting container process caused "process_linux.go:339: container init caused "process_linux.go:322: running prestart hook 0 caused \"error running hook: exit status 1, stdout: , stderr: time=\\\"2017-07-30T01:07:34Z\\\" level=fatal msg=\\\"failed to set gateway while updating gateway: file exists\\\" \\n\"""

I am running 17.06.0-ce on kernel 4.10.

Is this the expected behavior?

@rc979 you're commenting on a closed pull request; please open a new issue instead so that it doesn't get lost