ping @icecrime.

I will push a follow up PR today with the UX options for ipam in docker network create command.

(first) rebased on top of user-namespace support 🏃

Added UX and API for the ipam configurations. with corresponding integration-cli tests.

The ipam options in the UX demands some design explanation.
These options are exactly the same that we already have in docker daemon.

--ip-range is --fixed-cidr
--gateway is --bip
--subnet is subnet of --bip' (container subnet)

Prior to the new network UX, docker had just 1 network and that is the bridge network and the only way to configure it is via the daemon flags as mentioned above.

Now that we have multiple networks that are created by the user and backed by different plugins, we generalized it in the IPAM configuration via the above options. For backward compatibility reasons we mapped the older daemon options to the new IPAM configurations for docker0 bridge and hence the existing configurations are not impacted.

For the new networks created by docker network create, they all get the same functionality and more, based on the backend IPAM driver and Network Driver.

Tested network creates/subnet/connects along with loading external driver default IPAM Join() calls and they all worked as advertised 👍

What's the plan for documentation?

@tomdee the networking docs are being completely overhauled as part of https://github.com/moxiegirl/docker/tree/new-networking-docs. No point adding it now and changing it shortly after.

But, we are adding developer docs to the remote driver APIs in libnetwork project just like we have for remote network driver. thanks for opening moby/libnetwork#635

Cool, so IPAM will be covered in https://github.com/moxiegirl/docker/tree/new-networking-docs too? That sounds like a good plan.

I'm having some issues with this branch when running with a remote driver.

I'm starting the daemon with

sudo ip link set docker0 down && sudo brctl delbr docker0 && sudo ip link set docker_gwbridge down && sudo brctl delbr docker_gwbridge ;sudo docker-dev daemon -D

Then I try to create a network and it fails

$ docker-dev network create -d calico test
Error response from daemon: Invalid Address Pool

The daemon outputs

DEBU[0024] Calling POST /v1.21/networks/create          
INFO[0024] POST /v1.21/networks/create                  
DEBU[0024] calico's manifest: &{[NetworkDriver]}        
DEBU[0024] calico implements: NetworkDriver             
DEBU[0024] Allocating IPv4 pools for network test (fa4e29153232e1c9b4d9b95a2bfed93c909c1885b3b1d02f575b9aa807f17a1f) 
DEBU[0024] RequestPool(GlobalDefault, , , map[], false) 
ERRO[0024] Handler for POST /v1.21/networks/create returned error: Invalid Address Pool 
ERRO[0024] HTTP Error                                    err=Invalid Address Pool statusCode=500

Let me know if you'd like me to raise this as a separate issue.

@tomdee yes. the docs will be part of that effort.

The error message is originated from the calico driver. it is not a libnetwork issue.
We can chat in IRC and I can explain the network-driver role on how to make use of the IPAM data.

I've worked with @Madhu on IRC and identified a few issues here.

The problem I was hitting had nothing to do with the Calico driver. I could repro them all with the overlay driver.

1. Using a global driver (such as Calico or the Overlay driver) can't be used with Docker unless the daemon is started with the --cluster-store flag. The current error message (that I raised above Error response from daemon: Invalid Address Pool) is no good. It needs to tell the user that they need to start the Docker daemon with the --cluster-store flag since they are using a global driver.
2. Passing in subnet and ip-range to work around the problem docker-dev network create --subnet=10.10.0.0/16 --ip-range=10.10.10.0/24 -d overlay my_overlay causes docker to crash. Output is here https://www.irccloud.com/pastebin/JnugtTo3/
3. Using --cluster-store with etcd fails. ERRO[0012] Handler for POST /v1.21/networks/create returned error: failed to update store for object type *libnetwork.network: 104: Not a directory (/docker/network/v1.0/network) [10]

I'm going to continue testing using --cluster-store with consul.

can you make sure that any tests you added will not be run on lxc, so testRequires(c, NativeExecDriver)

It's green, LGTM (not dismissing Jess' previous comment, but just to say: I'm ok merging this).

ok ill fix the tests after if they need it :P (not being sarcastic im in the middle of doing this now for other things )

LGTM

Would be great to have bash completion for this before final release /cc @albers @mavenugo

@tiborvass think those are the changes in cc6aece,

thus --subnet, --ip-range and --gateway options in docker network command, and the --aux-address option?

Also,

/cc @sdurrheimer for zsh completions 👍

@thaJeztah Will do as soon as possible

I'll take care of bash completion, thanks for pinging me.

Thanks both!

@tomdee PTAL : #17046
Also, the etcd issue should have been resolved by now.