-
Notifications
You must be signed in to change notification settings - Fork 485
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
Implement conditional depends_on #453
base: main
Are you sure you want to change the base?
Conversation
f92d0b1
to
c2941da
Compare
The approach I'm aiming for delegate the logic to podman using
https://docs.podman.io/en/latest/markdown/podman-create.1.html#requires-container |
That only takes care of the case in which the condition is |
short syntax means require the container to be started. the down side of this is that it does not handle healthy either defined in the compose https://github.com/compose-spec/compose-spec/blob/master/spec.md#healthcheck
of in the dockerfile we can add a test with I'll post my personal opinion very soon
and they have built in port and tcp checks
|
This commit changes the way that depends_on blocks are parsed and tracked during the `podman-compose up` process. Each service's dependencies will be tracked as a dict in which keys are services being depended on and values are the condition to be met by said services before the current service can start. This lays the groundwork for supporting long-syntax / conditional depends_on blocks, but should not change any behavior so far. Signed-off-by: Adrian Torres <[email protected]>
This commit implements the long-syntax / conditional depends_on compose mechanism which instructs the compose system to wait for a certain condition before starting a container. Currently available conditions are: - service_started: same behavior as before this commit, the depending container will start as soon as the depended on container has started - service_healthy: if the depended on container has a healthcheck, wait until said container is marked as healthy before starting the depending container - service_completed_successfully: wait until the depended on container has exited and its exit code is 0, after which the depending container can be started This mechanism is part of the v3 [1] compose spec and is useful for controlling container startup based on other containers that can take a certain amount of time to start or on containers that do complicated setups and must exit before starting other containers. [1] https://red.ht/conditional-depends Signed-off-by: Adrian Torres <[email protected]>
c2941da
to
fcbf15e
Compare
I said:
so let's go first of all thank you for your contribution for context and vision please refer to our discussion here Regarding how docker-compose implements it and how should we follow compose spec since docker compose does not have k8s-like probes (started vs. ready vs. healthy) so regarding start condition, it should be with readiness not healthiness (because we don't stop the dependent one it when it later became unhealthy) a db and a web, we start the web after db is ready regarding if you have a real-world use case for |
Sure, I don't really care where it's implemented as long as it works, it's currently kind of a blocker for our project since we need the feature, so we've been debating migrating to The reasons I implemented it here are mostly:
This is a valid opinion but I'm not really looking to discuss semantics or challenge the compose spec status quo, this is just a feature that I need so I went ahead and implemented it as defined by the spec.
Yes, in fact in one of our branches in which we test |
we will carry your patch until podman have a solution and then we either detect the version or branch and state dependency (let's say podman-compose 1.2 requires podman 4.5 which has the fix, if you don't have it then use podman-compose < 1.2) I see you are interested in podman-compose that's why I'm trying to onboard you with the reasoning behind those choices. long long ago rootless podman did not have inter container communication, in podman compose we created a pod or a container then shared the network namespace between all the containers so that all containers were able to communicate using 127.0.0.1 then we used --add-host to simulate the DNS. later podman supported network, we no longer have this workaround we keep it in 0.1.x branch for those who have legacy version. similarly we will carry your patch until it can be done with podman. keep in mind the final objective is that currently because I'll recommend people to use systemd, cron jobs ...etc. your approach breaks this, it's more of just run it in I'll get back to read all of your points maybe this weekend. |
Hey no worries, take your time, I'm gonna leave some comments here but don't feel pressured into rushing your answers
I'm ok with that, I think it's important that
Definitely, hopefully me and my team can contribute more in the future :) I hope you didn't take my comment wrong, when I said I didn't care where it's implemented I was simply stating that for me it's fine either way
Did you mean it's not compatible? because if so I agree, if systemd units simply call |
Yes, here is the systemd unit
As you can see, we just assert container creation with It should work since we create them with |
Co-authored-by: Dawid Dziurla <[email protected]>
* Portable database health check to ensure that the Django migrations do not run until the database is fully up. The previous solution, to use the long form of `depends_on:` in our compose.yaml file, isn't supported by podman-compose: containers/podman-compose#453 * Switch to using a bash heredoc to more readably construct the Python script to be run.
@Elkasitu Just FYI, I would be open for this PR to land. If it improves compatibility with docker-compose, then it should land regardless of whether there are better ways to achieve something. There's been two years since this PR has been opened, so I understand it's likely you won't have interest in it anymore. Maybe someone else can pick this up in such case. |
@p12tic I can take a look, hopefully the conflicts won't be too much of a hassle |
This PR implements the necessary changes so that
podman-compose
complies with the compose v3 spec's long syntax for thedepends_on
block [1].This essentially means that services that depend on other services can be set up in such a way that they'll only start if the defined conditions are met for each service that it depends on.
[1] https://github.com/compose-spec/compose-spec/blob/0c768bea2e06d5550bc5f390bebe1f830dca8756/spec.md#long-syntax-1