Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support depends_on type service_completed_successfully #575

Open
micheljung opened this issue Oct 19, 2022 · 8 comments
Open

Support depends_on type service_completed_successfully #575

micheljung opened this issue Oct 19, 2022 · 8 comments
Labels
enhancement New feature or request

Comments

@micheljung
Copy link
Contributor

micheljung commented Oct 19, 2022

Is your feature request related to a problem? Please describe.

The problem is that podman-compose is incompatible with current docker-compose.yml because it does not support service_completed_successfully.

According to the compose spec

  • condition: condition under which dependency is considered satisfied
    • service_started: is an equivalent of the short syntax described above
    • service_healthy: specifies that a dependency is expected to be "healthy"
      (as indicated by healthcheck) before starting a dependent
      service.
    • service_completed_successfully: specifies that a dependency is expected to run
      to successful completion before starting a dependent service.

Describe the solution you'd like
podman-compose implements service_completed_successfully as per the spec.

Describe alternatives you've considered
None

Additional context
I didn't check if the other conditions are supported yet, but they should also be.

@micheljung micheljung added the enhancement New feature or request label Oct 19, 2022
@mbergen
Copy link

mbergen commented Dec 13, 2022

It seems like service_healthy also does not work.
service_started is the equivalent to no condition (default) and therefore works.
Would be great to get these working!

@mdellweg
Copy link

Actually, i think podman waits for the healthiness anyway, so anything one specifies behaves like service_healthy.

@mbergen
Copy link

mbergen commented Sep 20, 2023

Actually, i think podman waits for the healthiness anyway, so anything one specifies behaves like service_healthy.

Last time i checked it podman was not executing any healthchecks, it was only waiting for services to be started. That's a huge difference.

@Greenall
Copy link

Greenall commented Oct 4, 2023

I'm on the following versions and can confirm that service_healthy condition seems to be ignored and treated as service_started.
podman-compose version 1.0.6
podman version 4.4.1

@kontsaki
Copy link

kontsaki commented Feb 9, 2024

any status update on this feature?

any way to workaround this?

@w568w
Copy link

w568w commented Feb 10, 2024

@kontsaki Have a look at #453, which has a preliminary implementation of depends_on.

TL;DR (maybe inaccurate!): podman-compose is calling podman commands directly to do all stuffs (e.g. executing podman start foo --bar), which do not provide a way of "depending on" another container, because it needs a daemon to do that (as Docker does). There are some workarounds:

So, it is sad to say that there is still no good way to support it. I ended up having the container exit immediately when it fails to connect to the dependency container, and set restart: always.

@kontsaki
Copy link

I ended up using docker-compose provided by https://github.com/docker/compose and it works as expected with podman as the backend.

I have also installed the compat package podman-docker on Fedora, not sure if this makes podman run as daemon but currently everything works with rootless podman and all docker-compose features.

@candleindark
Copy link

@mbergen, @mdellweg, @Greenall I just filed a dedicated issue for the problem with the service_healthy condition.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

7 participants