| 6 Apr 2022 |
 @jhillyerd:matrix.org | 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:matrix.org | 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 |
|  @blaggacao:matrix.org 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:matrix.org | 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 |
| @blaggacao:matrix.org | 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 |
| @blaggacao:matrix.org | 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 |
| @blaggacao:matrix.org | That way people can modify the colmena interface at will and make it work for their code / project structure. | 00:38:52 |
| @blaggacao:matrix.org | Instead of doing complicated transforms to match the expected interface. | 00:39:24 |
| @jhillyerd:matrix.org | In reply to @schnecfk:ruhr-uni-bochum.de
So keys are only uploaded if you're using colmena, but not with the built flakes Thanks. I guess none of my services would start for local testing, so that's not really an option. 😕 I think I'll try agenix, that seems reasonable for homelab. | 00:40:59 |
| @blaggacao:matrix.org | * 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 idea 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:41:00 |
| @jhillyerd:matrix.org | Then again, I guess the host key would change for each VM... so maybe not. | 00:41:27 |
| 11 Apr 2022 |
| Zhaofeng Li | In reply to @blaggacao:matrix.org
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 idea 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. Sorry about the wait, and thing looks reasonable in the PR. I wanted to push 0.3 out (which has been stuck for quite a while) before merging, but got sidetracked by other stuff IRL. I'll hopefully get around to it later this week or next week. | 18:08:27 |
| @blaggacao:matrix.org | Oh great to hear! Yeah, I'm happy to get a little more involved with the codebase in the coming days / weeks. Planning on maybeMigrate 😂 | 23:24:16 |
| 12 Apr 2022 |
|  @linus:schreibt.jetzt joined the room. | 18:47:42 |
| 18 Apr 2022 |
 aanderse | any way to specify multiple colmena outputs in a flake? basically i want a repo that houses n "hives" and tagging isn't enough to keep them separate | 20:34:28 |
| aanderse | maybe something like outputs = { ... }: { colmena-hive-1 = { ... }; colmena-hive-2 = { ... }; } then pass a flag tocolmena to tell it which one to process? | 20:36:20 |
