 | Colmena | 317 Members |
| A simple, stateless NixOS deployment tool - https://github.com/zhaofengli/colmena | 107 Servers |
| Colmena | 317 Members |
| A simple, stateless NixOS deployment tool - https://github.com/zhaofengli/colmena | 107 Servers |
| Sender | Message | Time |
|---|---|---|
| 30 Jul 2022 | ||
 Zhaofeng Li | In reply to @winterqt:nixos.dev* By multi-arch, do you mean deploying to another architecture (https://colmena.cli.rs/unstable/examples/multi-arch.html) or something else? | 06:23:38 |
 Winter (she/her) | I mean having one hive with multiple architectures, as currently it seems that you need to do something like colmena.meta.nixpkgs = import nixpkgs { system = ...; }; | 06:24:46 |
| Winter (she/her) | Though it seems that eval.nix has support for just pointing that at a path to Nixpkgs | 06:25:09 |
| Winter (she/her) | So maybe it'll just work? | 06:25:13 |
| Winter (she/her) | Ah, here: https://github.com/zhaofengli/colmena/issues/31 | 06:26:22 |
| Winter (she/her) | Was looking for this | 06:26:26 |
| Zhaofeng Li | In reply to @winterqt:nixos.devYeah, it's suppported and you can set the nixpkgs.system in the node configuration. If you don't like overriding it this way, you can also set an instantiated nixpkgs of another arch in meta.nodeNixpkgs. | 06:26:44 |
| Zhaofeng Li | In reply to @winterqt:nixos.dev nixpkgs.system works now and if it doesn't, it's a bug | 06:27:57 |
| Winter (she/her) | I assume https://github.com/zhaofengli/colmena/issues/31#issuecomment-873348794 is still an issue, though, which is why it's still open? | 06:28:35 |
| Winter (she/her) | Hm, this is confusing; I can't seem to find the repro of the issue that still exists. | 06:30:20 |
| Winter (she/her) | They say the repro here was fixed, and then provide a workaround for here, but I'm not sure what the still broken usecase is. | 06:32:41 |
| Winter (she/her) | * They say the repro here was fixed, and then provide a workaround for some usecase here, but I'm not sure what the still broken usecase is. | 06:32:54 |
| Winter (she/her) | ugh element just stripped the formatting, cool | 06:33:05 |
| Zhaofeng Li | In reply to @winterqt:nixos.devI think it can be closed. One remaining issue was the merging of nixpkgs.config, which was broken because all of the config keys were untyped prior to 22.11 unstable. Now most of the config keys are typed and can be correctly merged. | 06:34:03 |
| Winter (she/her) | Ah, neat. I feel like I asked this before but I can't find the logs or any reasoning in the source, but why is impure evaluation used? Is it for the non-flake case or something? (Also, nix-eval-jobs is the default evaluator on master, at least until the chunked evaluator is ported over to the new trait, right?) | 06:38:50 |
| Zhaofeng Li | In reply to @winterqt:nixos.devIt's mostly because we have a custom entry point for our evaluation (eval.nix) and it's difficult to use it in pure evaluation mode. I recently did some experiments on that front, which is to make eval.nix and friends a flake so we can use builtins.getFlake with a locked URI to get it in pure evaluation mode. Going forward I think the easiest way is to generate a temporary flake that contains eval.nix with the hive flake as a locked input. | 06:46:22 |
| Zhaofeng Li | The chunked evaluator is the default, with nix-eval-jobs behind --evaluator streaming. There are still a few usecases nix-eval-jobs doesn't support, like remote builders during evaluation (needed for FOD with foreign architectures, used in mobile-nixos). | 06:47:52 |
| Zhaofeng Li | * The chunked evaluator is the default, with nix-eval-jobs behind --evaluator streaming. There are still a few usecases nix-eval-jobs doesn't support, like remote builders during evaluation (needed for <s>FOD</s>IFD with foreign architectures, used in mobile-nixos). | 06:51:11 |
| Winter (she/her) | In reply to @zhaofeng:zhaofeng.li Oh I missed it since I thought it would pass impure (which is the default for nix-instantiate, so obviously it doesn't), then I saw the comment and thought it was removed or something. For that IFD case, I assume it wouldn't be possible to setup something where we pass remote builders to Nix during eval (if that's possible) if ~~that wording probably doesn't make sense at all 😅~~ | 06:57:19 |
| Winter (she/her) | In reply to @zhaofeng:zhaofeng.li* Oh I missed it since I thought it would pass impure (which is the default for nix-instantiate, so obviously it doesn't), then I saw the comment and thought it was removed temporarily. For that IFD case, I assume it wouldn't be possible to setup something where we pass remote builders to Nix during eval (if that's possible) if buildOnTarget is true, so that's handled transparently? (that would require either being root on the remote host) ~~that wording probably doesn't make sense at all 😅~~ | 06:57:32 |
| Zhaofeng Li | In reply to @winterqt:nixos.devnix-instantiate already uses remote builders if configured globally, and we will pass --builders if meta.machinesFile is set. The problem is that nix-eval-jobs forcibly disables it due to an outstanding issue. | 07:01:59 |
| Winter (she/her) | I'm wondering if we can construct a builders argument with the data from the machines that have buildOnTarget set as well | 07:03:29 |
| Winter (she/her) | To transparently handle that IFD case | 07:03:38 |
| Winter (she/her) | Without manual configuration ahead of time | 07:03:44 |
| Zhaofeng Li | Yeah, it could work pretty well combined with the recent --eval-store suggestion. | 07:06:10 |
| Zhaofeng Li | The next step is to perform the actual evaluation remotely, but we aren't there yet. | 07:06:55 |
| Winter (she/her) | In reply to @zhaofeng:zhaofeng.liYeah, I did see that. Is that suggesting using the target machine as the store for eval with that flag? I'm pretty sure that's what they're suggesting, but the "local --eval-store" part is throwing me off. | 07:14:49 |
| Zhaofeng Li | Yeah, it's a bit confusing but I think that's what they meant. | 07:15:59 |
| Zhaofeng Li | In reply to @zhaofeng:zhaofeng.liOk, just tested, and the colmena apply-local --sudo test goal works as it currently stands. The interactive prompts of sudo don't use stdin/out. | 07:26:53 |
| Winter (she/her) | Oh, huh, they... don't? | 07:42:55 |