I see this is still pending any further discussion and feedback from @mavenugo @mrjana @aboch, but if you were to add HostPortStart to the PortBinding struct along with the RequestPortInRange func, that would provide full flexibility for allocating from port ranges as well as port persistence policies if they are ever accepted by the powers that be.

Basically the only further change we'd need to enable persistence rules from a libnetwork perspective is the equivalent of this: https://github.com/docker/docker/pull/12622/files#diff-fab6c6ef38a84cdb41a6ef028848f8a8R136

LGTM

@mavenugo @mrjana @aboch Any more reviews needed?

@dkjer Apologies on the delay. Will review this today and provide feedback.

@dkjer Appreciate your patience. implementation LGTM.

But I have a basic question on the use-case. I see a value of this as a daemon config.
Dont quite understand how a per-container port-range will help (even in the case of AWS security-groups that you mentioned in the Docker PR).

@mavenugo, I see @dkjer 's response is still pending, but if I might add - this does lay the ground work for the per-container port persistence policies covered in the closed docker PR #12622, which is something I plan to pick up again over here (but was waiting for the outcome of this PR).

Thanks @bru7us. But, this still doesnt answer why this configuration is a container specific ?
We could of-course make the persistence policy independent of the port allocation UI. Isnt it ?

@mavenugo, it's actually per-SPEC, much more specific than per-container. This allows you do have some ports published "internally" from the default ephemeral range, and then potentially some additional port(s) fully exposed that can be published through the AWS sec-group.

For persistence policies I think we definitely need to combine the port allocation and the policy rules as there is a concept of "soft persistence" where we request the initial port by providing a range to the allocation UI - a soft-persisted port would then request that same port but also provide the range - leading to a condition where the port is allocated if it is available, or a new one from the specified range if it is not available.

@mavenugo Agreed that it would make sense to define the port ranges at the daemon level as well.

However, as @bru7us mentions, this isn't really a per-container range. It is a per-port-spec range.

Our current use of this internally, is when using a container that needs a mix of port ranges (mapping to different aws security group ranges). We define our container port ranges using ECS task definition (using a separate patch to allow port-specs to bypass current ECS limitations). Sensitive ports are mapped into a range with increased security group restrictions. These ranges could be something that we define at the docker daemon level, however, and I could see that being a useful feature as well.

Thanks @dkjer for the explanation.