'deploy: replicas:' behaving differently after update to 2.3.0.5

[jeffkingtg]

• I have tried with the latest version of my channel (Stable or Edge)
• I have uploaded Diagnostics
• Diagnostics ID: B0DEC5A8-C324-4B0D-BEB7-D3369A8D406A/20200916202610

Expected behavior

When starting web service using docker-compose up, version '3', 'deploy: replicas: 2' should be ignored - https://docs.docker.com/compose/compose-file/#deploy

Actual behavior

Since the setting is set to 2, a second web server is started during docker-compose up. Causing an error due to the port being allocated to web_1. Setting the value to 'deploy: replicas: 1' fixes the issue.

Information

• macOS Version: 10.14.6

Immediately after updating to 2.3.0.5 I started experiencing an error using 'docker-compose up' on my local machine:

WARNING: The "web" service specifies a port on the host. If multiple containers for this service are created on a single host, the port will clash.
Creating server_web_1 ...
Creating server_web_1 ... done
Creating server_web_2 ... error

ERROR: for server_web_2 Cannot start service web: driver failed programming external connectivity on endpoint server_web_2 (b1ce68d35c4442072cf1f1fe1dc300e113baf57518c86aa2ff247cd2870a8cca): Bind for 0.0.0.0:9999 failed: port is already allocated

After running 'docker-compose down', I looked for anything using ports 8080 or 9999 and nothing came up.

Original setting:

version: '3'
services:
web:
image: "jetty:9.4.9-jre8"
...
ports:
- "8080:8080"
- "9999:9999"
deploy:
replicas: 2

After some tinkering, I changed replicas to 1 from 2 which fixed the error:

From looking at the documentation, it seems that the deploy setting should be ignored when using 'docker-compose up' (https://docs.docker.com/compose/compose-file/#deploy). The 2.3.0.5 update seems to no longer ignore this setting.

Diagnostic logs

Docker for Mac: version...

Steps to reproduce the behavior

1. Add 'deploy: replicas: 2' to a service (with a port specified?)
2. Using 'docker-compose up' attempt to start the service
3. An error should be thrown due to a port clash

[stephen-turner]

Thanks for the report, I'm moving this into the compose bug tracker.

[jamshid]

FWIW this new behavior where up respects deploy: replicas: (treating it like older scale:) was always desired by a lot of users e.g. #1661 (comment)

[bo5o]

It seems like some other keys in deploy besides replicas are also treated (incorrectly?) by docker-compose.
See this minimal example:

---                                                                                                                                                                                                   
version: "3.8"                                                                                                                                                                                        
services:                                                                                                                                                                                             
  whoami:                                                                                                                                                                                             
    image: traefik/whoami                                                                                                                                                                             
    deploy:                                                                                                                                                                                           
      mode: replicated                                                                                                                                                                                
      replicas: 4                                                                                                                                                                                     
      restart_policy:                                                                                                                                                                                 
        condition: on-failure                                                                                                                                                                         
        delay: 10s                                                                                                                                                                                    
        max_attempts: 5                                                                                                                                                                               
        window: 120s                                                                                                                                                                                  

When I spin up the service with docker-compose 1.27.4 I get the following output:

$ docker-compose up
WARNING: The following deploy sub-keys are not supported and have been ignored: restart_policy.delay, restart_policy.window
Starting ..._whoami_1 ... done
Starting ..._whoami_2 ... done
Starting ..._whoami_3 ... done
Starting ..._whoami_4 ... done
Attaching to ..._whoami_1, ..._whoami_2, ..._whoami_3, ..._whoami_4
..._whoami_4 | Starting up on port 80
..._whoami_3 | Starting up on port 80
..._whoami_2 | Starting up on port 80
..._whoami_1 | Starting up on port 80

So, four replicas have been started, but it also tells me that restart_policy.delay and restart_policy.window are ignored. Consequently, the others are not ignored? Let's try:

---
version: "3.8"
services:
  whoami:
    image: traefik/whoami
    deploy:
      mode: replicated
      replicas: 4
      restart_policy:
        condition: any
        delay: 10s
        max_attempts: 5
        window: 120s

I changed restart_policy.condition to any and see if that has any effect:

$ docker-compose up
WARNING: The following deploy sub-keys are not supported and have been ignored: restart_policy.delay, restart_policy.window
Recreating ..._whoami_1 ... error
Recreating ..._whoami_2 ... error
Recreating ..._whoami_3 ... error
Recreating ..._whoami_4 ... error

ERROR: for ..._whoami_4  Cannot create container for service whoami: maximum retry count cannot be used with restart policy 'always'

ERROR: for ..._whoami_1  Cannot create container for service whoami: maximum retry count cannot be used with restart policy 'always'

ERROR: for ..._whoami_3  Cannot create container for service whoami: maximum retry count cannot be used with restart policy 'always'

ERROR: for ..._whoami_2  Cannot create container for service whoami: maximum retry count cannot be used with restart policy 'always'

ERROR: for whoami  Cannot create container for service whoami: maximum retry count cannot be used with restart policy 'always'
ERROR: Encountered errors while bringing up the project.

It seems that this key is also read by compose and interpreted as restart policy 'always'

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[THeinemann]

FWIW this new behavior where up respects deploy: replicas: (treating it like older scale:) was always desired by a lot of users e.g. #1661 (comment)

Sorry for digging out an older issue, but I found the same behaviour.

From my point of view, I actually would like to use the replicas setting with docker-compose up, but it still contradicts the documentation, so I'm not confident that this would be future-proof.

Can I rely on this behaviour, or might it be that docker-compose up will ignore the replicas settings with the next bugfix release, to be consistent with the documentation? In the former case, the documentation should be adapted.

[stale]

This issue has been automatically marked as not stale anymore due to the recent activity.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because it had not recent activity during the stale period.