Control the startup order ?

[mmisztal1980]

Is tye capable of controlling the startup order in any shape or form?

For instance, I'd like to use an elasticsearch container, which can take ~60s to start, I wouldn't like to deploy my services beforehand.

In docker-compose v2, one could use the depends_on with healthchecks, to start dependent containers when their dependency was in a healthy state. A readiness probe, acting as the gate, would do as well.

Is this doable?

[tebeco]

not a maintainer here but what would be the ideal"synch" point ?

this specific one look like a custom route to call on elastic like a healthcheck and not a timer right ?

that is already doable with an httpclient call in a loop inside the Program.cs>Main of your webapi until you get a more official answer

also that would look like the equivalent of initContainer there was an issue about it few days ago is there a way to block the initContainer until done ? maybe yes or no or just a loop and curl ;)

[mmisztal1980]

I guess an equivalent of a readiness probe would be great. For instance - having an init container with a migrator for a pgsql database is pointless to start before and actual postgres container is up and ready to receive traffic, right?

[tebeco]

That could also works, it only depends on your particular needs TBH eg: If your limitation is to be able to Log, the readiness might not be good enought, since you'll loose startup logs (configuration exception)

Each scenario could/would have various soltuion on "synchronization" between projects

[mmisztal1980]

one would need to structure their tye.yaml in a way that ensures that core infrastructure is up and running 1st - which makes sense

[cecilphillip]

Control order would be also useful for non-application services. Things like rabbitMQ, Consul, vault and others that depend on each other but need to be started up in a specific order.

[tebeco]

To be fair, this look like this should be done by the application code and not dotnet tye. Especially because when you need, for example to patch the OS of a Node in AKS, K8s will try to drain pods from that node to other available node in the cluster. you might need to define pod affinity or "taint" to be able to be sure, for example, that all pods of "RabbitMq" are not on the same Node, but still the problem remains.

Your application should be resilent at startup time or at runtime against "middelware health" The ability to plug HealthCheck can (should/must) be used if you depend on an external system You could also plug the readinessProbe to avoid incomming traffic.

But adding api to "hope" startup time will be fine from tye will probably give a false sense of "resiliency" while this problem can happen at any moment in production

Here is something that happened last month:

• We had a Drain
• We had LOTS of pod on that node
• The min/max pod count (surge....) forced K8s to create before deletion
• The equivalent of "Rabbit/Consul..." was down for ... reason + attempt of Drain (like if you need "at least 3 pod for Rabbit to have a consensus)
• pods reach "max pod count" per node / per cluster
• no more pod for the "middleware" could be created
• the "app" could not start because the middleware was down

Basicly this looked like a Distributed Deadlock. If tye aim to help for kubernetes, adding feature for "Startup ordering" should not try to "create a non-existing concept" that tends to hide an issue in the codebase of your own application This will hurt very bad, and usually at the moment you really don't want this kind of scenario to fail

[JunTaoLuo]

I agree with what @tebeco mentioned. We don't think it's a good idea for tye to control the startup order of all services in general. That being said, ordering is valuable in some circumstances, for example requiring databases to be available. We have had similar discussions before, see number 3 in https://github.com/dotnet/tye/issues/486.