Colmena | 320 Members | |
| A simple, stateless NixOS deployment tool - https://github.com/zhaofengli/colmena | 108 Servers |
| Sender | Message | Time |
|---|---|---|
| 18 May 2022 | ||
| Effectively im using colmena + nixos-rebuild | 19:57:00 | |
In reply to @phaer:matrix.orgok that work locally with nixos-rebuild. This piece of code fails becuase overwrite nixpkgs-2205 for nixpkgs | 21:43:00 | |
| 21:43:21 | |
In reply to @phaer:matrix.org* ok that works locally with nixos-rebuild. This piece of code fails makes colmena overwrite nixpkgs-2205 for nixpkgs | 21:43:48 | |
* ok server1 = inputs.nixpkgs-2205.lib.nixosSystem { (...) } that works locally with nixos-rebuild. This piece of code fails makes colmena overwrite nixpkgs-2205 for nixpkgs | 21:44:21 | |
* ok server1 = inputs.nixpkgs-2205.lib.nixosSystem { (...) } works locally with nixos-rebuild. This piece of code fails makes colmena overwrite nixpkgs-2205 for nixpkgs | 21:44:30 | |
* ok server1 = inputs.nixpkgs-2205.lib.nixosSystem { (...) } works locally with nixos-rebuild. This piece of code makes colmena overwrite nixpkgs-2205 for nixpkgs | 21:44:42 | |
In reply to @janejasperous:one.ems.hostFor that to work, you'll likely also need to use nodeNixpkgs as described in the colmena manual | 22:59:32 | |
| 19 May 2022 | ||
In reply to @schnecfk:ruhr-uni-bochum.deof course, that works. but duplicate code. Could be interesting colmena accepts nixosSystem.config as is | 08:39:52 | |
Maybe I can change my shim a bit 🤔 Might be non-ideal. For example: nodeNixpkgs could probably be populated from nixosConfigurations.hostname.pkgs | 09:10:59 | |
| 17:33:16 | ||
| 21 May 2022 | ||
| 20:31:51 | ||
| 23 May 2022 | ||
| How colmena would look like in a nushell: | 05:17:05 | |
| * How colmena would look like in a nushell: (pseudo code) ```nu colmena | where tag = oakland | each { |it| ^colmena deploy ($it.fragment) } ``` | 05:17:58 | |
| 24 May 2022 | ||
any way to increase debug/error logging for the deployment.keys options? i'm not getting much and i don't know what i'm doing wrong | 20:27:15 | |
using keyCommand, btw | 20:27:33 | |
-v is as far as it can get at the moment, and it should dump stderr from the keyCommand when it fails | 20:53:35 | |
| ok thanks feel free to ignore this so i'm forced to level up my | 20:58:23 | |
The %DESTINATION% here is templated with key.path() which is generated from the modules which should only care about the latter name | 21:19:08 | |
| 26 May 2022 | ||
| 10:27:32 | ||
| Thanks for merging #73 | 19:04:15 | |
|
I wonder how we can settle this... Maybe I can convince you avout the A swappable | 19:06:24 | |
For example, what I did in std is just attach the tooling meta directly to drv or drv.meta upon which a bundler then can do fantastic stuff through a clean interface. | 19:07:36 | |
For example, to build a DAG of std targets: drv // { after = [ "othertarget" ]; } | 19:09:27 | |
Iiirc, the bundler interface, in reality is any -> drv. drv -> drv just being the "common" case | 19:11:28 | |
Ah, and https://github.com/kamadorueda/toros is taking slowly shape. 🚀 The name of the game seems to add all the builtins, now. But then it could be used for parallel eval and also better eval cache strategies could be implemented akin to numtide/nix-eval-cache. | 19:13:54 | |
| In my opinion, maintaining legacy nix support in-tree is a bit of a stretch and reduces the ability to innovate. Maby there can be a 2-tree solution that is not 100% mutually compatible | 19:23:47 | |
| * In my opinion, maintaining legacy nix support in-tree is a bit of a stretch and reduces the ability to innovate. Maby there can be a 2-tree solution that is not 100% mutually compatible . | 19:24:05 | |
| Looks like this iface should be enough, we could
| 21:46:33 | |
| The actual inteface seems even less:
| 21:55:35 | |