| 20 Feb 2024 |
|  @sofo:matrix.org changed their display name from Sofi to Sofie. | 07:39:10 |
| @sofo:matrix.org changed their profile picture. | 14:39:01 |
| @sofo:matrix.org changed their profile picture. | 14:41:30 |
| @sofo:matrix.org changed their profile picture. | 14:42:42 |
| @sofo:matrix.org changed their profile picture. | 14:44:01 |
| 22 Feb 2024 |
 raitobezarius | Zhaofeng Li: I'm planning to perform a big change in my fork of colmena, i.e. to introduce ways to configure flavors of systems, e.g. NixOS systems, Liminix systems, etc.
My intuition is that all that colmena really care about is NixOS-style mechanisms to copy closures to target system (if needed) and activate the new configuration, with that in mind, I am planning to introduce configuration attribute sets to influence how eval.nix works and which modules does it pass, which activation script will it use and introduce things like nixosConfigurations, liminixConfigurations in the top-level of the hive.
I am aware this is an intrusive change so I was planning to do it in my own fork of colmena and make a new tool out of this which will not be named colmena, I wanted to check with you if you were not interested into the idea (and if it could not make upstream). WDYT?
| 16:35:36 |
| raitobezarius | (To be precise, I'm adding support for Liminix systems and a certain framework to manipulate NETCONF-based appliances) | 16:36:06 |
 Zhaofeng Li | I'm actually interested in a deploy-rs-style "profile" system where the evaluator and deployer are pluggable | 16:37:40 |
| Zhaofeng Li | My main usecase would be to deploy nix-darwin | 16:38:11 |
| Zhaofeng Li | Been thinking about doing this for a while, haven't got the time yet | 16:38:43 |
| 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 |
