15 Jan 2022 |
angerman | * great. and now it fails to find my builders... | 13:53:21 |
Zhaofeng Li | It should use whatever is configured in nix.conf, or you can also set it in your config with meta.machinesFile: https://zhaofengli.github.io/colmena/unstable/features/remote-builds.html | 13:55:32 |
Zhaofeng Li | You can also use deployment.buildOnTarget to have it build on the remote node directly, but if IFD is in play you still need to set builders for evaluation | 13:56:40 |
angerman | whee, I got it to build. Let's see if it applies. | 14:28:22 |
angerman | Zhaofeng Li: sorry for the trouble that wasn't even yours really. | 14:28:40 |
Zhaofeng Li | No worries. I'm always happy to help 🙂 | 14:29:21 |
angerman | dealing with these kinds of indirect errors is tough. | 14:31:12 |
Zhaofeng Li | Yeah, especially for segfaults with no immediate cause in sight | 14:35:30 |
angerman | If you detect a segv from nix, maybe suggest to rerun the command with GC_DONT_GC :-) | 15:02:32 |
16 Jan 2022 |
| kraem set a profile picture. | 09:54:22 |
20 Jan 2022 |
| andi- left the room. | 00:09:12 |
22 Jan 2022 |
@github:maunium.net | [zhaofengli/colmena] CRTified opened
issue
#48: Add `${name}-key.service` unit files for `deployment.keys` entries
This is relevant for nixops -compability, as nixops uses these unit files as an indicator for other services that the key is available.
It's also helpful to prevent services from starting if the key is not available, e.g. in the case of unexpected (or in general external) reboots.
The definition in nixops uses inotifywait , but a path unit might be the more elegant way to solve this.
| 00:24:52 |
| phaer joined the room. | 09:03:13 |
phaer | In reply to @buckley310:matrix.org So I'm curious. In my setup my servers all exist inside of my flake outputs.nixosConfigurations, and my outputs.colmena is just a stub that consumes nixosConfigurations and emits a colmena configuration. Is anyone else doing it this way, or just me? I really like the portability of keeping my hosts in nixosConfigurations I am doing pretty much the same! While I like how you just do inherit (config.sconfig) deployment; to add deployment options, I wonder whether the colmena flake could expose a nixos module which includes the types of all deployment options, so that we could use nixosConfigurations for colmena.$host options directly, without getting an error that deployment options are undefined? | 09:10:26 |
Buckley | Yeah I thought about doing that. I had a look at the nix files in colmena and the deployment options aren’t currently exposed, but it looks like they could be | 09:12:09 |
@github:maunium.net | [zhaofengli/colmena] Repo forked into phaer/colmena | 10:04:28 |
@github:maunium.net | [zhaofengli/colmena] phaer opened
pull request
#49: eval.nix: expose nixosModules.deploymentOptions
Allow flake users to import .#nixosModules.deploymentOptions
into their flake, so that the same expression can be used for both,
.#colmena.$host as well as .#nixosConfigurations.$host, without the
latter complaining about undefined options in "deployment".
Tests seem to pass, building the manual still works and the resulting nixosModules.deploymentOptions works as expected in my configration. What do you think?
(reusing the same attrset for nixosConfigurations and colmena hosts only really works for setups which don't use the name and nodes parameters)
| 10:18:29 |
phaer | In reply to @buckley310:matrix.org Yeah I thought about doing that. I had a look at the nix files in colmena and the deployment options aren’t currently exposed, but it looks like they could be Just opened up a PR for that | 10:19:32 |
Buckley | I’ll test it | 17:07:49 |
23 Jan 2022 |
Zhaofeng Li | Basic support for nix-eval-jobs has landed in the main development branch, enabling true parallel evaluation that is also memory efficient. You can give it a try by passing --evaluator streaming and nix-eval-jobs will be used as the evaluator, spawning separate workers to evaluate nodes at the same time. | 02:15:07 |
Zhaofeng Li | So far the biggest issues I see with nix-eval-jobs mainly have to do with IFD. Builds triggered by IFDs cannot be easily cancelled, and there is no support for remote builders with IFD. | 02:15:19 |
@github:maunium.net | [zhaofengli/colmena] phaer synchronize
pull request
#49: eval.nix: expose nixosModules.deploymentOptions | 09:01:18 |
| Linux Hackerman joined the room. | 14:38:08 |
@github:maunium.net | [zhaofengli/colmena] lheckemann approved
pull request
#49: eval.nix: expose nixosModules.deploymentOptions | 14:41:42 |
@github:maunium.net | [zhaofengli/colmena] zhaofengli merged
pull request
#49: eval.nix: expose nixosModules.deploymentOptions | 18:06:42 |
Linux Hackerman | Is there a way to override an input flake like with the --override-flake nix option? | 19:03:09 |
Zhaofeng Li | Currently no, but we can add one. Looks like the argument is part of the common eval args in Nix, and accepted by both nix-instantiate and nix-eval-jobs | 19:06:24 |
Linux Hackerman | er, I think I meant --override-input not --override-flake | 19:15:14 |
Zhaofeng Li | Looks like I got them mixed up as well. --override-input is the useful one and it's not available in nix-instantiate or nix-eval-jobs . For flakes mode we could look into using nix eval --apply to evaluate, though I doubt our current setup would work in the pure evaluation mode. | 19:19:05 |
25 Jan 2022 |
@github:maunium.net | [zhaofengli/colmena] JCapucho opened
issue
#50: Nixpkgs fails to build on unstable
Hi, I'm using colmena with a flake to build a node that uses the nixos-unstable branch of nixpkgs (commit is https://github.com/NixOS/nixpkgs/commit/689b76bcf36055afdeb2e9852f5ecdd2bf483f87), but it's failing to build.
In the start of the log I see a warning with
capucho-nixos | trace: warning: The following Nixpkgs configuration keys set in meta.nixpkgs will be ignored: path
Which leads me to believe that the issue might be caused by ignoring the path attribute introduced in https://github.com/NixOS/nixpkgs/pull/153594
Here's the log of running colmena build --show-trace --verbose
log.txt
| 13:54:48 |