| 22 Feb 2024 |
 raitobezarius | I think my proposal is a generalization of that because for example for NETCONF switches, the concept of profile is virtual | 16:43:29 |
| raitobezarius | But yeah | 16:43:31 |
 Zhaofeng Li | Regarding top-level attributes, my plan was to make targets of different types available as nodes and allow them to cross-reference each other's configs like what we have currently | 16:53:25 |
| raitobezarius | not sure I follow exactly | 16:56:20 |
| raitobezarius | is your proposal to have deployment.deploymentType = "another-type"; ? | 16:56:29 |
| raitobezarius | if so, how do you dynamically switch the set of modules based on the type? | 16:56:39 |
| raitobezarius | cross reference becomes a bit harder if you try to mix different systems with different NixOS modules, no? | 16:57:03 |
 ma27 | fwiw what I've effectively done in my to-be-published solution is to expose nodes.<name>.os & nodes.<name>.configuration (I wanted to have deployment-wide modules, i.e. modules that are able to manipulate many machines). The latter's option type is generated by a function that takes a merge function and provides a type for that. The "merge function" can be something like nixos.lib.nixosSystem (or the nix-darwin equivalent), depending on what os looks like. The structure in nodes isn't mapped to config.system.build.toplevel, but left as-is to allow any part of any node to be evaluated with nix eval. Another module (when using it with flake-parts) fills nixosConfigurations/etc. with config.system.build.toplevel to allow nixos-rebuild to work with that. | 17:12:14 |
| Zhaofeng Li | In reply to @raitobezarius:matrix.org
is your proposal to have deployment.deploymentType = "another-type"; ? It'd would be defined inside each node and doesn't require invoking the module system to get. There can be a fallback to the NixOS evaluator if the node isn't an attrset or doesn't contain `type` | 17:15:50 |
| ma27 | In reply to @zhaofeng:zhaofeng.li
It'd would be defined inside each node and doesn't require invoking the module system to get. There can be a fallback to the NixOS evaluator if the node isn't an attrset or doesn't contain `type` that means this option must be defined in hive.nix and not in an arbitrary file, correct? | 17:16:53 |
| Zhaofeng Li | In reply to @raitobezarius:matrix.org
cross reference becomes a bit harder if you try to mix different systems with different NixOS modules, no? I don't think that's a big problem most of the case, when you refer to individual config keys that are pretty stable (networking.*) or your own modules | 17:18:09 |
| Zhaofeng Li | In reply to @ma27:nicht-so.sexy
that means this option must be defined in hive.nix and not in an arbitrary file, correct? It could be an import, from the user's perspective it would be something like `node1 = targets.nixos { ... }` | 17:19:33 |
| Zhaofeng Li | where targets.nixos is a convenience function that performs the wrapping | 17:20:06 |
| Zhaofeng Li | In reply to @ma27:nicht-so.sexy
fwiw what I've effectively done in my to-be-published solution is to expose nodes.<name>.os & nodes.<name>.configuration (I wanted to have deployment-wide modules, i.e. modules that are able to manipulate many machines). The latter's option type is generated by a function that takes a merge function and provides a type for that. The "merge function" can be something like nixos.lib.nixosSystem (or the nix-darwin equivalent), depending on what os looks like. The structure in nodes isn't mapped to config.system.build.toplevel, but left as-is to allow any part of any node to be evaluated with nix eval. Another module (when using it with flake-parts) fills nixosConfigurations/etc. with config.system.build.toplevel to allow nixos-rebuild to work with that. Interesting, the os key sounds like what I have in mind. I assume eval.nix would inject os for the deployment-wide modules to consume? | 17:23:41 |
| raitobezarius | I just find it weird it's an attribute set inside the system that modifies the loaded modules for the evaluation | 17:35:50 |
| raitobezarius | That means that you kinda introspect the system before calling lib.evalModules on it with the appropriate modules | 17:36:02 |
| raitobezarius | But I guess, this could be acceptable | 17:36:06 |
| raitobezarius | and how do you see configuring the dispatch for the switch case on the os attribute Zhaofeng Li ? | 17:37:09 |
| Zhaofeng Li | There would be a registry attrset with definitions for each target type, and the os attribute can either be a string (in which case it will look up the registry) or an explicit target definition | 17:40:45 |
| Zhaofeng Li | In reply to @raitobezarius:matrix.org
I just find it weird it's an attribute set inside the system that modifies the loaded modules for the evaluation Yeah, but it's mostly for backwards compatibility, newer configs should provide each node already wrapped | 17:42:11 |
| raitobezarius | what does already wrapped means | 17:42:25 |
| raitobezarius | because I'd imagine that | 17:42:28 |
| raitobezarius | targets.nixos cfg = cfg // { os = "nixos"; } ? | 17:42:46 |
| raitobezarius | or would you imagine | 17:42:52 |
| raitobezarius | targets.nixos cfg = { _type = "nixos"; module = cfg; ... } ? | 17:43:01 |
| raitobezarius | In reply to @zhaofeng:zhaofeng.li
There would be a registry attrset with definitions for each target type, and the os attribute can either be a string (in which case it will look up the registry) or an explicit target definition OK, how do you see the definition for activation ? | 17:43:13 |
| raitobezarius | right now, you can do colmena apply dry-activate, etc. | 17:43:28 |
| raitobezarius | how would we translate this in the registry configuration module | 17:43:37 |
| Zhaofeng Li | In reply to @raitobezarius:matrix.org
targets.nixos cfg = { _type = "nixos"; module = cfg; ... } ? This, which is closer to ma27 's model | 17:43:42 |
| ma27 | In reply to @zhaofeng:zhaofeng.li
Interesting, the os key sounds like what I have in mind. I assume eval.nix would inject os for the deployment-wide modules to consume? not sure if I have done that already (the current draft is very much oriented on what I needed), but it would be trivial. | 17:43:54 |
