Disnix does not activate services in dependsOn order

[philip-wernersbach]

Disnix currently does not activate services in the order established by dependsOn, but it should. For instance, if a service a dependsOn b, b should be activated before a.

Due to this bug, I cannot deploy anything on my Disnix cluster, as activation of services fails due to them being activated in the wrong order.

[svanderburg]

Maybe this has something to do with a silly requirement that I should have stated better in the manual (or maybe implement a check for this or a more robust method).

Can you check whether the 'name' property in services.nix of each service corresponds to the attribute name, e.g.

{pkgs, system, distribution, invDistribution}:

{
  serviceA = {
    name = "serviceA"; # identical to attribute name
  };
}

and whether the deployment works properly?

[philip-wernersbach]

I finally got back from vacation and the holidays, and got some time to look at this.

In my services.nix, the name of each service does correspond to its attribute name.

While I was checking that, I also noticed that I had a typo in the function that I used to generate my target specific services. The typo unfortunately was still valid code, but made my function not add anything to the dependsOn of my target specific services. I fixed it and everything works now! Sorry!

On another note, maybe it would be good to add functionality to generate target specific services from a "prototype" service, or add functionality to display a graph of the dependsOn of the services in services.nix? The former would have helped me avoid this, the later would have helped me debug it.

[svanderburg]

Hi, I just implemented something in the development version now that checks whether the name attribute matches the service's attribute name. This feature becomes part of the next Disnix release, so then you will get notified if you make such a mistake again.

About generating services from a prototype. I think the Nix expression language is already powerful enough to do something like this. For example, you could define an attribute set in a let-block which purpose is to be encapsulate common properties and reuse those properties somewhere in the body.

[philip-wernersbach]

Great! I'm very happy with anything that prevents me or my work team from making mistakes in Disnix.

The Nix expression language is indeed already powerful enough to do something like this. I'm currently doing it in my services.nix and distribution.nix files. But it required me to write complicated code that uses Nix's metaprogramming. I think target specific services are common enough in deployments that it would be nice to have something like this built into Disnix, even if it's just a Nix file that Disnix imports and passes to services.nix and distribution.nix.

[svanderburg]

Yes maybe you're right about making target-specific services better "first-class citizens" in the deployment models. I need to give this some more thought.

In addition to the examples shown in the blog post and manual, there are other kinds of scenarios possible that I have not investigated yet. For example, there is also the theoretical possibility to make a target-specific service an inter-dependency of another service, although I have not encountered such a situation in practice yet. :)

For all these scenarios it would (obviously) be nice to have a notation that allows us to neatly expresses them.