| 16 Feb 2024 |
 hexa | and like that 😄 | 14:21:12 |
| hexa | fails with localSystem = system the same 🙂 | 14:21:47 |
 raitobezarius | at this point, you want to confirm one thing | 14:24:17 |
| raitobezarius | can you evaluate your system toplevel without colmena? | 14:24:23 |
| raitobezarius | as long as you are not using colmena specific nixos modules, you can just do pkgs.nixos [ (import ./machines/configuration.nix) ] | 14:24:58 |
| hexa | deployment.keys | 14:26:48 |
| hexa | agenix soon-ish | 14:26:59 |
| raitobezarius | you can inject colmena specific modules too in that list | 14:28:00 |
| raitobezarius | and that will fix the thing | 14:28:03 |
| raitobezarius | here's an example on how I do it with flake: | 14:28:08 |
| raitobezarius | https://git.newtype.fr/newtype/newtype-org-configurations/src/branch/main/configurations.nix#L19-L21 | 14:28:38 |
| 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 |
