[zaptheimpaler]

Fundamentally, each of the tasks is a separate job. Why not just order the jobs in an array and start them in order? So if a job at some index needed to be restarted/started for some reason, you would first go through and start everything before it.

More generally, looks like you just form a DAG to map out the dependencies and use it to figure out what to do. The daemon could then periodically traverse the DAG starting from the root to each leaf starting jobs as required. Could you explain why this kind of approach was unfeasible in your scenario?

[avalanche123]

Well, success of a job is transient and not permanent in this case. Like I mentioned before, successful boot of a dependency doesn't mean that dependency exists by the time we get to boot a host. You need to continuously check the status of your group to determine actions that can be taken for current state. A stateful system that marks a job as complete upon successful execution wouldn't work. DAG computation does happen, but inside MoreHostsCanBeBooted condition that is a pre-requisite for BootMoreHosts action. If what you're proposing is to re-run the same job until target state transition has been achieved and code job in idempotent way, then this is essentially what's being done with the current approach, except there are no jobs, and idempotency is a side-effect of not tracking progress. I hope my explanations make sense :)