| 5 Apr 2022 |
 jhillyerd | Hi. Thinking about moving my legacy nixops config over to colmena+flakes. I know colmena doesn't create machines on the fly, which is fine since I'm running my setup on bare metal. But I like testing on VMs first when I make big changes. How does one go about testing against a staging environment in colmena? Import that same config into two different host entries? | 23:49:02 |
 CRTified | In reply to @jhillyerd:matrix.org
Hi. Thinking about moving my legacy nixops config over to colmena+flakes. I know colmena doesn't create machines on the fly, which is fine since I'm running my setup on bare metal. But I like testing on VMs first when I make big changes. How does one go about testing against a staging environment in colmena? Import that same config into two different host entries? You could use a shim like this: https://github.com/zhaofengli/colmena/issues/60#issuecomment-1047199551 and stay consistent with the de-facto flake output standard. Then, you could use the resulting derivation at self.nixosConfigurations.<name>.config.system.build.vm to run the VM as it was possible with nixos-rebuild build-vm | 23:53:12 |
| 6 Apr 2022 |
| jhillyerd | So if I'm reading that right, you are configuring your system using the nix flake nixosConfigurations syntax, then mapping it into the colmena attribute? | 00:00:40 |
| CRTified | Exactly | 00:00:53 |
| jhillyerd | I guess that leaves the other half of my question, applying the same config to two different machines... I suppose I could just use nixos-rebuild with the flake and --target-host pointing at my test vm? | 00:02:52 |
| CRTified | Something like this in your flake should give you the VMs as a nix build .#vm-hostname target:
packages = with nixpkgs.lib;
mapAttrs' (host: sys: {
name = "vm-${host}";
value = sys.config.system.build.vm;
}) self.nixosConfigurations;
| 00:03:19 |
| CRTified | I'm doing something similar, by cross-compiling SD-Images for my aarch64 hosts | 00:03:39 |
| CRTified | (But there I'm filtering to check whether the sdImage build output exists) | 00:04:55 |
| jhillyerd | Oh nice. That would leave me with a script similar to nixos-rebuild build-vm ? | 00:11:38 |
| CRTified | exactly | 00:11:43 |
| CRTified | Note that you don't need these packages - you can access that attribute directly like this: nix build .\#nixosConfigurations.<hostname>.config.system.build.vm | 00:14:17 |
| CRTified | Result looks like this:
$ find result/
result/
result/system
result/bin
result/bin/run-cottonbox-vm
| 00:15:03 |
| CRTified | (and the run-cottonbox-vm script spawns the qemu instance) | 00:15:33 |
| jhillyerd | Cool. So it sounds like step 1 for me is to move my existing nixops into a flake, get the test vm running, then I can look at mapping the flake into colmena. | 00:22:51 |
| CRTified | Yes, that's a plan | 00:23:55 |
| CRTified | jhillyerd: although I'm heading to bed now, feel free to ping me. I did exactly the same migration from nixops to colmena+flakes | 00:40:19 |
|  David Arnold (blaggacao) joined the room. | 05:00:56 |
| 7 Apr 2022 |
|  Mark joined the room. | 08:17:39 |
| 8 Apr 2022 |
| CRTified | Sooo, building on the VM question: Did someone happen to stumble across a method of testing the whole deployment at once in VMs? Otherwise, I'll see whether I can build on the config.system.build.vm derivation and create a script that runs them in the same network | 15:13:14 |
 Zhaofeng Li | Not a real answer, but maybe you can take a look at the e2e tests that I have: https://github.com/zhaofengli/colmena/tree/main/integration-tests/apply | 18:10:53 |
| Zhaofeng Li | But yeah, I kind of want a nice setup to do something like that as well | 18:11:15 |
| CRTified | In reply to @zhaofeng:zhaofeng.li
But yeah, I kind of want a nice setup to do something like that as well I think it would generally be nice to have some place to collect useful snippets like the one I've posted in https://github.com/zhaofengli/colmena/issues/60 | 23:11:56 |
| 10 Apr 2022 |
| jhillyerd | I finished porting my old nixops config to a standard (not colmena) flake. Next I need to figure out secrets, as the janky system I was using previously doesn't work with flakes. Does the colmena secret deployment system work with the pure build environment of flakes? | 00:23:40 |
| CRTified | If you use the config.system.build.vm-path for the flakes, then there is no implementation for "uploading" the keys. I did not look into doing that myself, but might need to do soon | 00:30:33 |
| CRTified | * If you use e.g. the config.system.build.vm-path for the flakes, then there is no implementation for "uploading" the keys. I did not look into doing that myself, but might need to do soon | 00:30:44 |
| CRTified | So keys are only uploaded if you're using colmena, but not with the built flakes | 00:31:00 |
| David Arnold (blaggacao) | https://github.com/zhaofengli/colmena/pull/73 i wanted to quickly ping, to see if this is mergeable stuff. I think it's a neat ides to spin this further so that projecta can declare their local evaluator (which is great for lowering the magic) while still using upstream options and modules. | 00:37:14 |
| David Arnold (blaggacao) | I think the next improvement to this PR would be to make the evaluator configurable, so that it doesn't need to be patched into the binary. | 00:38:12 |
| David Arnold (blaggacao) | That way people can modify the colmena interface at will and make it work for their code / project structure. | 00:38:52 |
| David Arnold (blaggacao) | Instead of doing complicated transforms to match the expected interface. | 00:39:24 |
