Add service ordering - #3
Conversation
|
I this implementation complete for both containers and NixOS system ? |
490d074 to
7c428fa
Compare
7c428fa to
3cff77c
Compare
|
@Prince213 , are you able to resolve the conflict ? Thanks |
Related-to: ngi-nix/forge#173
3cff77c to
1bf114a
Compare
eljamm
left a comment
eljamm
left a comment
There was a problem hiding this comment.
I'm testing this in ngi-nix/forge#287, but the ordering doesn't seem to be taking effect.
| referencedDeps = lib.pipe config.ordering [ | ||
| builtins.attrValues | ||
| (map (o: o.after)) | ||
| lib.flatten | ||
| ]; |
| let | ||
| inherit (lib) mkOption types; | ||
|
|
||
| serviceNames = builtins.attrNames config.services; |
There was a problem hiding this comment.
prefer lib instead of builtins, since the latter is tied to the Nix implementation, whereas the former is fixed to the current Nixpkgs.
| pub struct ServiceOrdering { | ||
| /// Services that must have started before this one is spawned | ||
| #[serde(default)] | ||
| pub after: Vec<String>, |
There was a problem hiding this comment.
would adding before complicate things or would it be fine?
| self.detect_cycles() | ||
| } | ||
|
|
||
| /// Detect cycles in the ordering graph via iterative DFS. |
There was a problem hiding this comment.
Maybe we can explain what this means and does in more details? both in general and how it related to service ordering
|
@Prince213 , @eljamm is reporting that ordering doesn't work/doesn't have any effect . Are you able to help us ? |
Introduce `readyCheck` on services (a polled executable that exits 0 when ready) and a corresponding `afterReady` ordering option that blocks a service's spawn until all listed dependencies pass their readiness check. Adds per-service `ready` watch channels alongside the existing spawn channels, a configurable timeout (default 30s), and NixOS assertions ensuring `afterReady` targets always declare a `readyCheck`.
71ee75d to
f578468
Compare
imincik
left a comment
imincik
left a comment
There was a problem hiding this comment.
Concerns regarding consistency of implementation with systemd where raised during our weekly meeting. Let's have a second look and improve this feature where needed.
|
@eljamm , I think, first design choice we need to make here is whether we want to leave ordering orchestration on nimi on all runtimes OR we delegate it to some other tools if they exist on particular runtime (e.g. systemd on nixos runtime). Your decision to manage ordering on NixOS with systemd looks correct to me. But in this case, we should implement Nimi's ordering (for containers) as much as consistent with systemd as possible. We don't need to support all systemd features, we should choose only some limited subset. |
3 participants
Related-to: ngi-nix/forge#173