opened
IlyaSkriblovsky
username_0
While this is true for almost any regular web app, I can't agree with that for something more stateful. For example, when my service receives stop signal, it gracefully closes all active connections and saves log records on each disconnection to DB. I'm trying to dockerize my app with Compose and this seems to be an issue :(  Thanks for advice.

For example, both SysV and Systemd have means for dependency-ordering both starting and stopping of services. I bet you won't like if your PC will unmount filesystems before all your apps is closed while shutting down :)
Dependency-ordered stop
issue
created
andrenarchy
username_1
+1 for stopping processes in the reverse order of starting them. btw: this is also how [maestro-ng](https://github.com/signalfx/maestro-ng) handles it.

Concerning the quote of @username_3: I disagree because sending `SIGTERM` doesn't mean that everything is going down chaotically but actually gives the process a way to shut down gracefully.
comment
created
IlyaSkriblovsky
username_0
Any comments from maintainers?

If the general idea of dependency-ordered service stopping (using `links` and `volumes_from` as implicit dependency specifications) will be approved by project maintainers, I will try to implement it and create a pull request.

I've read almost all discussions here about introducing `depends_on` or other possible explicit dependency syntax, but failed to understand whether any of such ideas are approved and planned for implementation? Will Compose have any means of inter-service dependency tracking when linking will be eventually removed from Docker? Using `volumes_from` for stating dependencies looks like a dirty hack.
comment
created
dnephin
username_2
If we add a new `depends_on` key to the upcoming V2 config format (#2504) then it would make sense to allow it to be used for shutdown as well as startup.

I don't think we've made any decision here yet, but it does seem to be a highly requested feature, so it's very likely we will provide something.

I don't think we're ready for a PR just yet. If we do add it, it will likely only be for the V2 format, which isn't ready just yet. We also need to decide exactly what the scope of `depends_on` would be.
comment
created
IlyaSkriblovsky
username_0
The ordering by `links` and `volumes_from` can be implemented right now without introducing any additional syntax. Compose already does ordering while starting up, I just suggest to add same ordering to shutting down.

It can be done even better than just stop containers sequentially in reversed order: some services can be stopped in parallel while they are not `link`ed together. Btw, same trick can be done for speeding up `start`: currently all services are started one-by-one, but it might be quicker to start in parallel ones that doesn't depend on each other.

I can work on it if you and other maintainers don't mind against this feature. This change isn't require any syntax additions, just adding to shutting down what Compose already does on `start` and `up`.
comment
created
andrenarchy
username_1
@username_0 I'd also vote for implementing it now since all required information is already there and it doesn't break the interface/syntax.
comment
created
dnephin
username_2
Links are being removed from the V2 format, and I don't think we want to add anything new to the V1 format, so I don't think it makes sense to add shutdown ordering using links.

There is still a trade-off here. Doing the operation sequentially means that your container startup and shutdown is going to be quite a bit slower, even with the optimistic strategy you describe where you start everything once its dependencies are ready (original issue #1984).

By replacing links with user defined networks, and by replacing volumes_from with named volumes we don't have to enforce any order at all, and get basically the same feature set, with much faster startup and shutdown time.

I acknowledge that for some use cases it may be preferred to have slower operations for the well defined order, which is why it's important to use a different field. It should be possible for someone to use network container aliases (the replacement to links) without being forced to have an ordered startup and shutdown.

By separating these concerns, I think we can satisfy more use cases.
comment
created
IlyaSkriblovsky
username_0
Actually, with my suggested approach startup will be _faster_, not slower. Currently Compose starts containers sequentially, one-by-one, in dependency order (`parallel.parallel_start` is only used when scaling, not for `up`/`start`). So, my approach will always be faster for startup (except one corner case when all your containers are linked in linear chain, which is rarely the case, I think). That's why this was requested in #1984.

Stopping will be slower than now, but 1) I think startup time is more important; 2) stopping behavior would be more consistent with startup behavior.

BTW, I already have algorithm demo written for such sequential/parallel approach: https://gist.github.com/username_0/7c27ae970ee38c20e73a

But I will understand if you will reject this suggestion because this interferes with work on V2 format.
comment
created
aanand
username_3
This sounds like a sensible plan for `start` and `stop`.

I think we should retain the current behaviour of `kill`, however (i.e. no ordering) - it's useful to have a way to shut down the app as quickly as possible without caring about cleanup, and `kill` expresses that intention.
comment
created
IlyaSkriblovsky
username_0
Sure, `kill` should be unordered and completely parallel just as it is now. Ordering is only needed for graceful shutdown which is not the case while `kill`ing.
comment
created
IlyaSkriblovsky
username_0
Please see #2679
comment
closed
shin-
username_4
issue