[BUG] `docker-compose -f docker-compose.yml -f path/to/another/docker-compose.yml down` doesn't stops and removes all containers when started with specific profile

[tinogo]

Description

Hi,

I don't know, if I just missed reading it in the changelog, that there seems to be slight behaviour change between docker-compose v1 and v2 when stopping an environment with the --file option.

Steps To Reproduce

1. Execute docker-compose -f docker-compose.yml -f in/another/directory/docker-compose.yml --profile=foo up -d
2. Let everything start
3. Execute docker-compose -f docker-compose.yml -f in/another/directory/docker-compose.yml down

Actual behaviour:

• with docker-compose v2: Only the service(s) without a specified profile get stopped and removed
• with docker-compose v1: All services get stopped

Expected behaviour: docker-compose v2 should either behave the same as docker-compose v1 or this behaviour change should at least documented somewhere (at least I haven't found anything regarding this).

Compose Version

docker-compose v1:
docker-compose version 1.29.1, build c34c88b2
docker-py version: 5.0.0
CPython version: 3.7.10
OpenSSL version: OpenSSL 1.1.0l  10 Sep 2019

docker-compose v2:
Docker Compose version v2.17.2

Docker Environment

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.10.4
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.17.2
    Path:     /usr/libexec/docker/cli-plugins/docker-compose
  scan: Docker Scan (Docker Inc.)
    Version:  v0.23.0
    Path:     /usr/libexec/docker/cli-plugins/docker-scan

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 599
 Server Version: 23.0.2
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 1e1ea6e986c6c86565bc33d52e34b81b3e2bc71f
 runc version: v1.1.4-0-g5fd4c4d
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 5.15.0-69-generic
 Operating System: Ubuntu 22.04.2 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 30.9GiB
 Name: l19it
 ID: TE7P:YGLD:H7P5:EREK:4UYI:NOHQ:DYBM:RZDX:NPT3:ZJQ6:6LRB:O7PT
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Anything else?

No response

[milas]

Can you give a minimal example with 2x Compose files to illustrate what you're talking about? Is this when using depends_on, for example?

[tinogo]

Hi @milas,

I've created an example repo (https://github.com/tinogo/dc-repro) and updated the issue title and description while trying to track down the "real" culprit:

It seems it is now (with dc v2) necessary to also state the --profile when downing a Docker Compose environment if it has been started with a specific profile before (this wasn't necessary with dc v1).

[ndeloof]

As you run docker-compose -f some-compose-file down, compose will parse the compose file and doing so will only consider the declared services, we have many users relying on this behavior to partially shut down their stack, but keep some services up.

If you want all services to be stopped, you can either enable all profiles with --profiles="*" or run down command with just a project name, no compose file, so compose will search for containers with the matching project label and stop them all.