Skip to content

Feature Request: Node Dependencies #374

Description

@cazier

I'd like to be able to label nodes as having a dependency of other nodes, so that if I do an apply, particularly with the --reboot flag, it will wait for those previous nodes to be completed.

In my specific usecase, my configuration affects systems that are only available via an SSH ProxyJump, but the router that they proxy through is also maintained with Colmena. As such, I have to run the deployment as two separate commands:

$ colmena apply --on @routers --reboot
$ # Wait for them to complete
$ colmena apply --on @webservers --reboot

My proposal is to include a new value in the node config to include things the node depends on, and, if those are in the apply set, wait for them to "finish" before beginning.

For example, with a sample config as shown below:

{
  zone-a-router = {
    deployment.tags = ["routers"];
    services.firewall.nat.enabled = true; 
  };
  zone-a-server = {
    deployment = {
      tags = ["servers"];
      dependsOn = ["@routers"];
    };
  };
  zone-b-server = {
    deployment = {
      tags = ["servers"];
      dependsOn = ["@routers"];
    };
  };
  site-storage = {
    deployment.dependsOn = ["@routers" "zone-a-*"];
  };
}

The example may be a bit contrived, but I wanted to show how I want it to still use all the same matching as the --on <NodeFilter> flag, but in order to create a dependency graph of nodes.

In the example above, I would imagine the following invocations:

$ colmena apply --on "@routers,zone-a-server" --reboot
Apply zone-a-router first, reboot it, apply zone-a-server and reboot that too
$ colmena apply --on "@routers,@servers" --reboot
Apply zone-a-router first, reboot it, apply all the servers in parallel (up to the parallelism limit), and reboot them too
$ colmena apply --on "@routers,site-storage" --reboot
Apply zone-a-router first, reboot it, apply site-storage, reboot that.

A few rules:

  • A node only continues when the previous node is "done", which means after the reboot, if the --reboot flag is supplied.
  • If a node fails, any subsequent nodes that depend on it will not be run.
  • If a node is not explicitly matched with one of the --on tags, anything that depends on it will not "trigger" the dependency.
    • So in example 3, since zone-a-server did not get included in the --on tags, site-storage will not wait for it to be completed (though it will obviously still wait for @routers to finish.
  • Cyclic dependencies (i.e., @routers depending on say @servers and @servers depending on @routers would raise a ColmenaError, prior to attempting to do any deployment.

I'd be interested in trying to implement this, if there's maintainer interest in the feature. (Also, if there are other rules that I'm missing, I'd be interested in those too!)

Activity

  1. stepbrobd commented on Jul 27, 2026

    @stepbrobd
    Member

    related #151

    for me personally i don’t think using node selector as dependency descriptor is a good idea, the first proposal makes more sense to be but the implementation wouldn’t be too easy

  2. cazier commented on Jul 29, 2026

    @cazier
    Author

    I think this is a separate feature than what is detailed in the referenced ticket. (Though I would also like to see some exclusion as detailed in the comments in the ticket. The ! and & use could be rough though...) Creating the dependency graph would be distinct, but complementary to that feature. Ultimately, I can do what I need now, with two separate commands, but that doesn't seem as elegant.

    Could you expand on why you think using the node selector is bad? I think there's room to simplify the feature by only matching exact node names (and tags, since that's the particular feature I need most 😬), and not the full GlobPattern match.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions