Open UnKulMunki opened 1 year ago
I think it's on line 2059-2065 of podman_compose.py:
thread = Thread(
target=compose.podman.run,
args=[[], "start", ["-a", cnt["name"]]],
kwargs={"obj": obj, "log_formatter": log_formatter},
daemon=True,
name=cnt["name"],
)
But I can't understand WHY you would force an -a
if that wasnt added to the podman start args???
G...C
Removing the "-a" does in fact fix the issue for me.
Suggested fix in Pull Request: https://github.com/containers/podman-compose/pull/564
@UnKulMunki I came across this issue while investigating another one I'm having with podman-compose
, but not with docker-compose
. I have a couple of YAMLs describing a set of services, and my intention is to run single service (container that runs some tests with pytest
framework) that requires a few dependencies like memcached and mysqld.
With docker-compose
my command is like:
docker-compose -f docker-compose.yml -f test.yml up --exit-code-from backend-test backend-test
and it effectively starts my test container (backend-test
) attached, and everything else detached. Once backend-test
finishes, docker-compose
exits with its status code.
With current devel version of podman-compose
, I'm getting all containers (backend-test
+ its dependencies) started in attached mode, and when backend-test
finishes, podman-compose
will wait forever for remaining dependency containers (memcached, mysqld).
I tried to apply your patch from https://github.com/containers/podman-compose/pull/564 and it expectedly changes the behavior - all my containers run detached, and podman-compose
exits immediately. This is better but still do not match docker-compose
behavior.
(I'm incorporating some tooling into CI pipelines, and having test output in stdout/stderr is absolutely essential.)
why not just pass -d
like this podman-compose up -d
; then use logs
@muayyad-alsadi -d
1) won't allow to get exit code from specified container, 2) will exit immediately - such behavior will require additional logic around implementing extra "wait until it's done" cycle.
The same scenario implemented surprisingly good in docker-compose
, and it would be really great to mirror the same approaches.
Describe the bug the command :
podman-compose -f=compose.yml
is actually appending the '-a' switch to the start command:podman start -a <CONTAINER_NAME>
This is a problem because I am stuck staring at the the last container's log entries as they pop onto the screen. Only a CTRL-C gets me out of that and also kills the last container. or doing a
CTRL+Z
and thenbg
to send to to background processing. This is of course a problem because I am trying to script automated service building.To Reproduce Steps to reproduce the behavior:
podman-compose -f=<DIR_NAME>/compose.yml up
Expected behavior containers start in a detached mode by default unless a podman-start-args switch is given for -a or --attached
Actual behavior the '-a' switch is being appended to the start commands for each container:
podman start -a <CONTAINER_NAME>
So I am stuck attached to the last container startedOutput
Environment:
Additional context I am trying to use podman-compose in automated container building for a CI / CD pipeline. Therefore getting stuck with attached containers is sub-optimal.
Thank you for your attention. G...C