 | Nix: Cloud Native | 248 Members |
| 56 Servers |
| Nix: Cloud Native | 248 Members |
| 56 Servers |
| Sender | Message | Time |
|---|---|---|
| 24 Oct 2025 | ||
 lillecarl | * I've also got terragrunix in the early stages. Right now it's missing generating the TF lockfile in a drv (required since TF wants to write the lockfile temporarily in module dir but it's RO), it's going to be terragrunt + terranix essentially. Reminds me of the time when I came into a consulting job where they had 300 Terrraform states for one environment, someone somehow misunderstood terragrunt and split essentially every resource into it's own terragrunt unit. I quit that job, it was a loser society 😸 | 00:36:51 |
| lillecarl | I don't think Terragrunt is worth the effort when rendering config with Nix anyways, it really really tries to own tofu more than I'd like it to. What do you guys use to manage multiple states and data between them? terranix + some build system and remote_state? | 22:29:40 |
| 27 Oct 2025 | ||
 genadij.udarov joined the room. | 16:35:29 | |
| 28 Oct 2025 | ||
 puffnfresh joined the room. | 08:30:03 | |
| 31 Oct 2025 | ||
 purrtner joined the room. | 23:56:13 | |
| 2 Nov 2025 | ||
| lillecarl | Still looking for Kubernetes users to try out nix-csi! 😄 It's got a in-cluster cache (ssh-ng) now and you can reuse "builder nodes" as your own build cluster. The cache pod maintains a /etc/nix/machines config you can SCP onto your machine and with some ssh_config you get all builder labeled nodes accessible from nix CLI on your machine: ^ Pretty much like this, the list is always up2date on the cache (watching pod nix-csi-node pod events). Works with aarch64-linux and x86_64-linux so for cross-building it's pretty neat. Still investigating the proper way to trigger cache population within the cluster when doing remote builds | 17:03:49 |
| lillecarl | * Still looking for Kubernetes users to try out nix-csi! 😄 It's got a in-cluster cache (ssh-ng) now and you can reuse CSI pods as your own build cluster. The cache pod maintains a /etc/nix/machines config you can SCP onto your machine and with some ssh_config you get all builder labeled nodes accessible from nix CLI on your machine: ^ Pretty much like this, the list is always up2date on the cache (watching pod nix-csi-node pod events). Works with aarch64-linux and x86_64-linux so for cross-building it's pretty neat. Still investigating the proper way to trigger cache population within the cluster when doing remote builds | 17:04:42 |
 Zhaofeng Li joined the room. | 17:30:41 | |
 Erik | @lillecarl:matrix.org: first time I have heard of nix-csi, definitively I will give a try. I found it really amazing! | 20:49:02 |
| lillecarl | Erik: It's still ~quite beta~, but I'm happy to provide some hand-holding 😄 | 20:49:58 |
| lillecarl | * Erik: It's still ~quite beta~, but I'm happy to provide some hand-holding 😄 The CSI bit works well, the cache bit works well if you hold it right-ish, hehe. There isn't an option to add your own caches and trust-keys currently so the beaten path is adding your pubkey and pushing to it, or providing expressions in the volumeAttributes | 20:51:34 |
| Erik | And how a container is invoked with nix-csi? | 20:53:53 |
| Erik | What I understand is that nix-csi avoids the necessity to an adapter like nixify to consume nix builds, or maybe i had misunderstood... | 20:56:01 |
| Erik | * What I understand is that nix-csi avoids the necessity of an adapter like nixify to consume nix builds, or maybe i had misunderstood... | 20:56:16 |
| lillecarl | Erik: Yeah, and it's zero copy too. you provide a volume to the pod. On it you put volumeAttributes. Either you put down ${system} = pkgs.whatever; or you put down expression = ''full independent nix expression''; In the first operating mode the storepath must be available on a cache, in the second one it'll build it in-cluster and store it on the built-in cache | 21:18:54 |
| lillecarl | The thing with running on the CSI layer is that you must still specify a container image (quay.io/nix-csi/scratch:1.0.1 which sets PATH to /nix/var/result) and you get the zero copy /nix from nix-csi 😄 So it's a bit different as you specify the "image" through volumes rather than image, but it's what you've got to do to operate on the CSI layer 😄 | 21:20:55 |
| lillecarl | There's nix-snapshotter which does the same thing on the CRI level but then you need their containerd and NixOS on the Kubernetes host, nix-csi can just be deployed anywhere Kubernetes runs any CRI which doesn't create VMs work 😄 | 21:21:54 |
| Erik | really interesting | 21:23:10 |
| Erik | I will give a try for sure | 21:23:40 |
| lillecarl | https://gist.github.com/Lillecarl/3104898680ff9bd6128b6f4ddc2072e4 <- example podspec | 21:24:45 |
| Erik | Yeaaaah, i have stalikng your repo already | 21:25:14 |
| Erik | i got the main idea | 21:25:20 |
| Erik | is really powerful | 21:25:32 |
| lillecarl | There's integration with "easykubenix" too that makes it very easy to build manifests and push them to a cache 😄 | 21:25:35 |
| lillecarl | Well, easykubenix just makes it easy to stringify manifests and has a "preDeployScript" that you can use to push the manifest you've built to a cache, and since the derivation in the volumeAttrs is a dependency of the manifest it's pushed | 21:26:19 |
| lillecarl | The projects are still "rough around the edges" but it's all working, I'm using it on a greenfield on-prem Kubernetes thingy I'm building for a client | 21:26:59 |
| lillecarl | But something like this would ofc work too | 21:28:36 |
| Erik | Obviously nix is the perfect glue | 21:29:40 |
| Erik | as always | 21:29:49 |
| lillecarl | In reality nix-csi is essentially "nix copy --to /a/cool/path && mount --bind /a/cool/path $targetpath" but instead of "nix copy" we rsync and initialize the DB separately, which makes it 0 storage overhead and sharing inodes which is cool if you wanna run 999999 of the same pod on the same machine 😄 | 21:30:42 |