Round-robin container attribution on service network_mode

[lphuberdeau]

Before this patch, all slave containers would have the equivalent of "container:primary_1" as a network mode. The patch applies a round-robin logic to container attribution. I won't affect previously created containers, but at least allows scaling services that depend on the service network mode

Sample compose file:

primary:
    image: ubuntu
    command: sleep 60
slave:
    image: ubuntu
    command: sleep 60
    network_mode: "service:primary"

Sample set-up:

docker-compose up -d
docker-compose scale primary=2
docker-compose scale slave=5

[dnephin]

Thanks for the PR. We had a chance to discuss it briefly at our maintainers sync-up today.

Unfortunately I don't think we're going to be able to accept this change. It's an interesting idea, but I don't think it's a robust solution to the problem. This "pod-like" functionality really needs to be supported by the engine running the container, not just the client.

We'd also like to stop using these sequence numbers, see #1516, so adding more features that depend on them will make this more difficult.

[lphuberdeau]

Assigning the network mode to the first service in the list is rather arbitrary and prevents any kind of scaling. Without using numbers, random allocation would be better than the current situation. For small volumes, or when stricter relations are required, it would be unusable however.

For the random vs numbering, could it be optional? Random is good for some cases, but numbers re really useful when affinity is required. We have some cases where we need multiple workers per main containers, others where there is a one to one relationship, and others where it's the more trivial horizontal scaling.

I could convert the logic here to take the container name based on the selected scheme and apply the best logic possible.

[shin-]

My understanding is that this change is now obsolete when using the v2/v3 format and new networking. I'll go ahead and close this.