I have mixed feelings about this type of change but we need to get a +1 from @shykes if this is a type of setting that we want to expose to the end user.

I think the pros outweigh the cons for being able to do this.

This patch currently works only for IPs that are in the docker bridge subnet. I updated the API to explicitly state that. If required, I can send another patch to make it work for any IP.

Ping @shykes.

See also #6101. I personally think that solution is much nicer. If you want a specific IP address, you'd simply pass a /32.

Actually, it appears I misread that other PR. That sets the subnet docker can pick from at the daemon level (for all containers). Apologies.

However I do think the ability to pass docker a address block which it can pick the container IP from is more useful than having to specify a single IP. Something like docker run -t -i --ipblock 172.17.0.128/28 fedora. Then if you wanted a single IP, you'd just use a /32 (or make /32 the default if not specified).

This PR is missing documentation in cli.md, docker-run.1.md and possibly in networking.md.

In addition to all the comments, the code also doesn't validate that the requested IP is within docker's subnet.

I believe this is made obsolete by #7436, which would be a more flexible addition. Close in favor?

Hi, we just did an in-depth review of #7436 (comment). Everything I said there also applies here. Copying full content for convenience:

Sorry for late review.

All the maintainers agree that this is needed, in some form. There should be a way to configure different network ranges for different containers. The "multi-tenant product" use case you describe is totally valid.

There is a general concern with mixing 2 different types of configuration in the same API. It's not unique to this PR, but reviewing this triggered a long conversation about that problem. Basically, we believe that infrastructure-specific config, like "allocate this IP range", or "use this storage driver", or "mount this directory from the host", should not be exposed over the docker API, because they violate separation of concerns. The Docker API should be used to consume infrastructure - not define it.

In the case of this specific PR, your use case would be enabled by wrapping the docker client, rather than hooking it. Generally we want to encourage hooking instead of wrapping, because you can easily compose hooks, but you cannot compose wrappers.

Because of this, we are suggesting the following:

Don't expose this feature in the API. So, I'm afraid we're going to close this PR. Again, really sorry for coming in so late, I know you've put considerable effort in reacting to code review. FYI we are working on a better design process, so that you can get a design proposal approved first, and then send implementation, which should avoid such waste of time.

Instead, we really really want to make this feature available via hooks. It just so happens that we are starting work on plugins for Docker. We are going to use this use case as the 1st use case for plugins. This will be a joint effort between @erikh (who is handling various network-related improvements atm), @dmcg (who contributed the communication layer we'll use for plugins), @ibuildthecloud (wants plugins to contribute another network feature), @jfrazelle @crosbymichael @dmp42 (doing this review with me), @cpuguy83 (playing with docker+libchan).

TLDR: we're closing this but a shitload of people want to implement it in a different way, and build something very important for the project in the process. You are welcome to join the fun :)