Open sanzoghenzo opened 2 weeks ago
One way to try to solve that is to create a DAG based on the external resources declared in the stacks, but it would be a ton of work for little gain. Another, simpler approach would be to queue a failed deployment for retry at the end of the update stacks cycle, with a backoff limit to avoid infinite loops (it may be the case when one forgot to add a resource, either manually or via another stack)
Or we can add something like depends_on
in stack definition, similar to compose but for stacks
Or we can add something like
depends_on
in stack definition, similar to compose but for stacks
Maybe I'm too ahead of time, but this would not work well with #23 especially if stacks that match a wildcard path have dependencies between each other. Anyway, this can wait until the other, more important issues are solved
There are some cases where there's the need of deploy stacks in a certain order.
A common example is deploying a single reverse proxy (traefik in my case) in its own stack and then attach the services to be published to the same network (declared as external in their stacks):
At first boot SwarmCD could try to deploy the dependent services (whoami in this case) before the dependency (traefik), and this results in an error; only the dependency is deployed and one needs to wait the next cycle to get everything up and running.
While this could be a rare event (mostly during the bootstrap phase of a new infrastructure), it would be nice if we don't have to wait that long to reach consistency.
One way to try to solve that is to create a DAG based on the
external
resources declared in the stacks, but it would be a ton of work for little gain. Another, simpler approach would be to queue a failed deployment for retry at the end of the update stacks cycle, with a backoff limit to avoid infinite loops (it may be the case when one forgot to add a resource, either manually or via another stack)