[BUG] With -p option, down stops and removes all containers regardless of config files

[yokonao]

Description

Premise

• I have multiple compose files.
• Use -p and -f option

Summary

After creation multiple containers, trying to down the one side leads all containers being stopped and removed!
In detail, please refer to Steps to Reproduce.

Expected

Only one container is to be stopped. (As Docker Compose V1 is like that)

Steps To Reproduce

1. Prepare two config files (e.g. mysql.yml and redis.yml)
2. Start containers using separated commands with -p option.

$ COMPOSE_IGNORE_ORPHANS=true docker compose -f mysql.yml -p some-project up -d 

$ COMPOSE_IGNORE_ORPHANS=true docker compose -f redis.yml -p some-project up -d 

3. Try to stop an one container.

COMPOSE_IGNORE_ORPHANS=true docker-compose -f ./mysql.yml -p some-project down
[+] Running 2/2
 ⠿ Container some-project-mysql-1  Removed                                                                                                               1.9s
 ⠿ Container some-project-redis-1  Removed                                                                                                               0.2s

4. Two containers are stopped and removed. I expected that only mysql container is down.

Compose Version

Docker Compose version v2.10.2

Docker Environment

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc., v0.9.1)
  compose: Docker Compose (Docker Inc., v2.10.2)
  extension: Manages Docker extensions (Docker Inc., v0.2.9)
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc., 0.6.0)
  scan: Docker Scan (Docker Inc., v0.19.0)

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 86
 Server Version: 20.10.17
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 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 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 9cd3357b7fd7218e4aec3eae239db1f68a5a6ec6
 runc version: v1.1.4-0-g5fd4c4d
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.10.124-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 8.746GiB
 Name: docker-desktop
 ID: V2PT:7RHH:JHBL:AASO:A65J:JEHM:HZ6T:QWKD:ATU6:46GI:MAB4:B7ZV
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5000
  127.0.0.0/8
 Live Restore Enabled: false

Anything else?

This issue is related to #9554.
But, the above is incomplete and not accourding to CONTRIBUTING.md. So, I recreated.

A similar bug occurs with other commands (e.g. stop or kill)

P.S.
This bug is an obstacle for migration to V2.

[yokonao]

@chris-crone @ndeloof

I'm sorry to bother you when you're busy.
Could you please confirm this bug as it is a big hindrance to using V2?
I am also creating a PR.

Sincerely.

[glours]

Hey @yokonao
The behaviour is the one expected regarding the current usage of the -p flag, it allows you to execute those commands start, stop, down, restart, pause, remove, exec ... without the need of a config file (using -f flag).
So when you use -p flag with -f flag, the 2nd one is not used when executing the command, that's why all your containers are stopped with the down command, we look at the current running stack and stop all the services.

The PR you opened can't be merged as it will remove the capability to down a stack with only the name of the Compose project (imagine if you removed your project directory or you compose file, you can't stop the stack via Compose)

But I get your point of being able to use -p in addition of a subset of the stack passed via a config file using -f flag, this could be an interesting way to improve the capability offered by the Compose CLI.
IHMO that should be part of a more wide evolution of Compose and the ability of supporting dynamic changes of a Compose stack.

Anyway there is a solution to unblock you, if you use profiles you should be able to only stop the services of your desired compose file.

[yokonao]

Hi! @glours
At first, thank you for your prompt reply and detailed explanation! I'm very sorry that this behavior was not a bug.

I understood that using -p and -f options is not intended. And your explanation about -p option makes sense.
But, this is an incompatibility with Docker Compose V1 and we have to stop using -p option.

I would like to confirm, but even if I use -p and --profile option, Compose CLI stops all containers in project? (I experimented in local)

[glours]

@yokonao you're right, using profiles isn't a work around in this case 😞
I'll work on a PR to manage that properly and not only for the down command.
I think you can close your PR, your changes will introduce side effect when no config file is provided which isn't expected.

[yokonao]

@glours

I'll work on a PR to manage that properly and not only for the down command.

Great! I expect your work.

I think you can close your PR, your changes will introduce side effect when no config file is provided which isn't expected.

Sure. I closed my pull request.

[ndeloof]

This has been fixed by #9375