`podman-compose up` error message suggests to use --replace option which is misleading - it does not exist

[Fak3]

Describe the bug

podman-compose up gives misleading error message:

Error: creating container storage: the container name "podtest_myservice_1" is already in use by 
86c42c65343b40e1ee7798daf3e7493d9fd2c6fcb08467b8730d008c3f88b920. You have to remove 
that container to be able to reuse that name: that name is already in use, 
or use --replace to instruct Podman to do so.

But the there is no --replace option for docker-compose

To Reproduce

1. mkdir mydir
2. create minimal docker-compose.yml:

   services:
     myservice:
       image: alpine
       volumes:
         - ./mydir:/mydir:U
       command: touch /mydir/myfile
   

3. run podman-compose up
4. run podman-compose up again

Expected behavior

I expected to get a suggested option to force-replace container with docker-compose.

Actual behavior

Message says to use --replace option which does not exist for docker-compose

Output

> podman-compose version
podman-compose version 1.3.0
podman version 5.3.1

Environment:

• OS: opensuse tumbleweed

[Fak3]

Attmpt to pass --replace with --podman-args fails:

> podman-compose --podman-args=--replace up
Traceback (most recent call last):
  File "/home/u1/.local/bin/podman-compose", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/home/u1/.local/share/pipx/venvs/podman-compose/lib64/python3.11/site-packages/podman_compose.py", line 3711, in main
    asyncio.run(async_main())
  File "/usr/lib64/python3.11/asyncio/runners.py", line 190, in run
    return runner.run(main)
           ^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.11/asyncio/runners.py", line 118, in run
    return self._loop.run_until_complete(task)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.11/asyncio/base_events.py", line 654, in run_until_complete
    return future.result()
           ^^^^^^^^^^^^^^^
  File "/home/u1/.local/share/pipx/venvs/podman-compose/lib64/python3.11/site-packages/podman_compose.py", line 3707, in async_main
    await podman_compose.run()
  File "/home/u1/.local/share/pipx/venvs/podman-compose/lib64/python3.11/site-packages/podman_compose.py", line 1861, in run
    retcode = await cmd(self, args)
              ^^^^^^^^^^^^^^^^^^^^^
  File "/home/u1/.local/share/pipx/venvs/podman-compose/lib64/python3.11/site-packages/podman_compose.py", line 2672, in compose_up
    await compose.podman.output(
  File "/home/u1/.local/share/pipx/venvs/podman-compose/lib64/python3.11/site-packages/podman_compose.py", line 1428, in output
    raise subprocess.CalledProcessError(p.returncode, " ".join(cmd_ls), stderr_data)
subprocess.CalledProcessError: Command 'podman ps --replace --filter label=io.podman.compose.project=podtest -a --format {{ index .Labels "io.podman.compose.config-hash"}}' returned non-zero exit status 125.

[Fak3]

Another issue - The podman-compose --podman-args=--replace up should print the actual error message from podman:

Podman returned non-zero exit status 125 
Error: unknown flag: --replace
See 'podman ps --help'

Currently it is just uninformative subprocess.CalledProcessError: Command 'podman ps --replace --filter label=io.podman.compose.project=podtest -a --format {{ index .Labels "io.podman.compose.config-hash"}}' returned non-zero exit status 125.

[madsl]

Is there a way to get around this error? Hitting this myself...

[madsl]

Seems like a solution is to use podman-compose --podman-run-args=--replace up -d

[mattsains]

I notice that podman-compose up --force-recreate exists and is probably what it should recommend?

[robertaistleitner]

I guess podman-compose should detect if stuff needs to be recreated the same way as docker-compose does it?

--force-recreate has a heavy impact on performance if it blindly recreates all containers if e.g. only settings for a single service changed.

[rafalkrupinski]

I'm getting this error when running with the same compose file as before, so it shouldn't even make any complains, just restart services

[mabasic]

This is strange. With docker its just starts my services, but with podman-compose it seems like it tries to create the volume again, instead of attaching to the existing volume

[doc-sheet]

Hi!

Here is simple fix for this issue #1251

I can try to make it ready for merge if that solution is fine.

[lh123]

@doc-sheet Just checking in — any update? We're encountering the same issue in the VS Code devcontainer.

[art-solopov]

The funny thing is that (for me at least) despite the error, it still starts the container all right.