WIP vision for builders data model (build capabilities) #9899
Conversation
| const std::string sshKey; | ||
| const unsigned int maxJobs; |
There was a problem hiding this comment.
Actually removing this is probably wrong, because it can be used to represent a limit on a single resource, such as an x86_64 + i686 build capability, or the resources of VMs (+ non-VM capabilities) such as an aarch64-darwin host with an aarch64-linux build VM.
So yes, we probably want maxJobs in both the machine and in the capabilities.
This limit may be crude, but the same idea applies when it's, say, a (cpu, memory) tuple instead of a single number of jobs; that's an orthogonal issue.
|
I don't think we need much incrementality/deprecation cycles on the C++ level. I'm fine just forcing the needed changes through Hydra (now that I've made it start using Nix's |
| /** | ||
| * Which derivations can be built. | ||
| */ | ||
| BuildCapability capability; |
There was a problem hiding this comment.
Should be a list of capabilities, because of shared resources? Alternatively, see https://github.com/NixOS/nix/pull/9899/files#r1478444104
Do we still conflate too many concepts? Maybe we need a build routing tree that's about available resources (and load). Each node may or may not impose restrictions on builds that are routed through it. Each node may or may not have information about how to contact a builder.
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/2024-03-11-nix-team-meeting-132/42960/1 |
Motivation
Current goal is to agree on terminology.
I'm not actively working on this.
End goal is to have more flexible and accurate dispatch.
See
build-capability.hhfor the new concept.machines.ccsuggests a path for introducing this incrementally.Context
Everything starts with a good data model.
Priorities and Process
Add 👍 to pull requests you find important.
The Nix maintainer team uses a GitHub project board to schedule and track reviews.