| 5 Apr 2023 |
Sandro | unless I should write a half backed and probably bad test | 12:27:50 |
| @rimuru:gentoo.chat changed their profile picture. | 12:28:12 |
| @mlyx:matrix.org joined the room. | 18:47:29 |
| 6 Apr 2023 |
| kadawee joined the room. | 01:02:49 |
| 7 Apr 2023 |
| Aaron Siddhartha Mondal joined the room. | 03:44:18 |
| Tom Purl (he/him) changed their profile picture. | 19:34:58 |
| 9 Apr 2023 |
| toonn changed their profile picture. | 14:12:16 |
| 10 Apr 2023 |
| @0xmrtt:envs.net joined the room. | 09:24:55 |
| tea joined the room. | 13:59:13 |
| 7c6f434c joined the room. | 14:03:28 |
7c6f434c | So, for a given set of derivations to build, bundling them as deps to a single named Hydra job does not help the scheduler at all? (Moving a conversation from ofBorg room — in particular with K900 —about what is «a lot» of really cheap to build packages, and are there any ways to affect it) | 14:07:50 |
K900 | No, it doesn't | 14:08:01 |
K900 | Every .drv is still scheduled separately | 14:08:07 |
7c6f434c | So only merging into a single multi-output derivation would help (but with other drawbacks, of course) | 14:10:57 |
K900 | Yes | 14:12:02 |
K900 | But we don't want to do that | 14:12:05 |
K900 | It's not like we're hitting any real limit | 14:12:18 |
K900 | It's mostly just that the queue runner is old and janky and not very fast | 14:12:39 |
K900 | But it could be made a lot faster | 14:12:44 |
vcunat | With large number of jobs, I suspect the cost (apart from evaluation) is about S3 queries on all output paths across Atlantic (and serialized, I suspect) and then potentially moving lots of data to/from builders. | 14:15:57 |
vcunat | * With large number of jobs, I suspect the cost (apart from evaluation) is about S3 queries on all output paths across Atlantic (and serialized, I suspect) and then potentially moving lots of data to/from builders (some of which could again be relatively far). | 14:16:59 |
vcunat | That's for hydra.nixos.org in particular. Normally you'd probably try putting all the machines close together... | 14:18:36 |
| 11 Apr 2023 |
| @lab-cat:matrix.org joined the room. | 16:06:44 |
| 12 Apr 2023 |
| Yuddite G joined the room. | 09:09:28 |
| 14 Apr 2023 |
aciceri | Have I to do something in particular in order to make remote builder for a different system work on Hydra?
nix = {
buildMachines = [
{
hostName = "rock5b.fleet";
system = "aarch64-linux";
maxJobs = 6;
speedFactor = 2;
supportedFeatures = ["nixos-test" "benchmark" "big-parallel" "kvm"];
mandatoryFeatures = [];
sshKey = "/etc/ssh/ssh_host_ed25519_key";
}
];
distributedBuilds = true;
};
I've this on my machine (x86_64-linux) and I can confirm that I can remote build using nix build <drv>, in Hydra UI "machines" page I see both localhost and ssh://rock5b (aarch64-linux). I've also configured ssh access for the hydra user, so I can access the remote builder using ssh being the hydra user (simply added the ssh keys to /var/lib/hydra/.ssh). Still hydra doesn't build aarch64-linux derivations and gives me "unsupported system type" :(
Am I missing something?
| 07:54:27 |
aciceri | PS: I'm using hydra from a pretty recent nixos-untable updated days/weeks ago | 07:56:36 |
aciceri | Logs don't help, if I manually restart the build from the UI I get this:
Apr 14 09:57:07 mothership hydra-queue-runner[929743]: aborting unsupported build step '/nix/store/cf0kfmf12cqrcvjjsp48zbzp20nw1q5q-treefmt.toml.drv' (type 'aarch64-linux')
Apr 14 09:57:07 mothership hydra-queue-runner[929743]: marking build 371 as failed
| 07:58:10 |
vcunat | I don't really know these things, but I'd look if this appears right: /admin/machines | 08:01:05 |
vcunat | * I don't really know these things, but I'd look if this appears right: http://*/admin/machines | 08:01:20 |
aciceri | Checked, it appears and with same fields I've set in nix.buildMachines | 08:02:37 |