Colmena | 331 Members | |
| A simple, stateless NixOS deployment tool - https://github.com/zhaofengli/colmena | 116 Servers |
| Sender | Message | Time |
|---|---|---|
| 20 Sep 2022 | ||
err, yes. Thank you. I thought because I did an --on @homelab parameter it would ignore the hosts that don't match. that was sloppy thinking. | 20:49:02 | |
Yeah, when matching against tags, currently Colmena will evaluate the deployment.tags for all nodes so that triggered the error | 20:58:58 | |
| 21 Sep 2022 | ||
In reply to @zhaofeng:zhaofeng.li
Looks like this breaks | 00:50:59 | |
In reply to @winterqt:nixos.devOops, let me look at it and fix when I get home | 03:58:37 | |
| (also need to add better integration tests for flakes) | 03:59:04 | |
In reply to @winterqt:nixos.dev* Oops, let me look at it and fix when I get home (Edit: fixed) | 06:41:29 | |
| 10:06:04 | ||
| 22 Sep 2022 | ||
| Yay for colmenaEval and makeHive, this is exactly what I wanted | 09:50:38 | |
I have another request: In flake-enabled deployments, can we pass the nixpkgs flake so that the hive expression can use nixpkgs.lib.nixosSystem and get the proper system.nixos.(revision|versionSuffix)? | 09:51:51 | |
| * Yay for colmenaHive and makeHive, this is exactly what I wanted | 10:08:39 | |
| 12:48:28 | ||
| 25 Sep 2022 | ||
| hm, I ran into a weird issue | 05:38:42 | |
| I was having a problem building redis | 05:38:51 | |
| specifically I got this exception:
| 05:39:30 | |
| which I believe was coming from this test in redis' source: https://github.com/redis/redis/blob/b414605285244c453f3fadbbe7a157cd83ed5f59/tests/unit/other.tcl#L334 | 05:39:41 | |
| which calls this code: https://github.com/redis/redis/blob/13d25dd95eec5e21925ef474b5d43f2acb23e54e/tests/support/util.tcl#L616 | 05:39:56 | |
| which does:
| 05:40:12 | |
and when colmena tries to deploy from my laptop, I have /usr/bin/pgrep installed at that path in my normal OS | 05:40:37 | |
I was able to work around this by renaming /usr/bin/pgrep on my system and then building locally | 05:40:56 | |
| I'm not sure what the principled way to solve this is | 05:41:05 | |
this is basically a failure of hermeticism, right? the redis build was happening on my system and it has one bit of source code that looks at /usr/bin/pgrep. is there a principled way in nix to make that not visible to derivations being built? | 05:41:49 | |
In reply to @yuka:yuka.devI guess this is issue https://github.com/zhaofengli/colmena/issues/60 | 08:15:39 | |
| 26 Sep 2022 | ||
| where does colmena cache tarballs? I think it is failing to register that a tarball has been updated | 00:41:15 | |
| what tarballs? | 01:03:12 | |
In reply to @rendakuenthusiast:imperishable.nameTypically you would patch/rewrite the package to not point at /usr/bin, example for regular grep: https://github.com/NixOS/nixpkgs/blob/4e62b94df308e197c1f107564ebdb4318bb80e27/pkgs/development/libraries/nss/generic.nix#L61 | 04:59:20 | |
Winter (she/her): I'm using builtins.fetchTarball to fetch an additional module with some custom modifications I made, from a server I control | 05:00:44 | |
jhillyerd: where does that substituteInPlace function come from? is that supposed to be shell code? | 05:01:59 | |
| I believe it is one of the shell functions that mkDerivation provides | 05:05:43 | |
In reply to @rendakuenthusiast:imperishable.nameHmm, pgrep should have been added when the tests were enabled in https://github.com/NixOS/nixpkgs/commit/835c3419d9b9 | 19:42:12 | |
In reply to @rendakuenthusiast:imperishable.nameI recommend adding a sha256 to the fetchTarball call so it's pinned to the specific version of the module and cached correctly. If you don't have a sha256, Nix itself has some time-based caching (need to look at the expiration - don't know offhand) | 19:44:50 | |