Consumable system features

[dasJ]

Is your feature request related to a problem? Please describe.

Consumable system features would open up a lot of possibilities for better load balancing, especially for Hydra build slaves. Examples of a consumable feature could be a CPU or a gigabyte of memory. Currently there is not really any good way to do load balancing for derivations for anything other than CPU usage, and consumable features could be a really great way to allow users to do this effectively. This can be useful for managing any kind of specialized hardware resource exposed / accessible in the sandbox, e.g., if a sandbox-mapped device has a limited number of handles that can be opened at a time.

Querying the system features would allow Hydra to perform better load balancing and distribution of consumable features like bandwidth, GPUs (do people do this?), …

Describe the solution you'd like

Example build machines file with scratchy having 32 "mem" features (e.g., it might have 32GB of memory):

nix@scratchy.labs.cs.uu.nl  i686-linux      /home/nix/.ssh/id_scratchy_auto        8 1 kvm,mem:32
nix@itchy.labs.cs.uu.nl     i686-linux      /home/nix/.ssh/id_scratchy_auto        8 2
nix@poochie.labs.cs.uu.nl   i686-linux      /home/nix/.ssh/id_scratchy_auto        1 2 kvm benchmark

The generic syntax for these features would be:

• feature → provides an unlimited amount of this feature (for example kvm)
• feature:n → provides n of this feature

A derivation should likewise be able to specify how many of each consumable feature it consumes. e.g., could use this syntax:

requiredSystemFeatures = [ "kvm" "mem:4" ];

The generic syntax for requiredSystemFeature would be:

• feature → requires this feature but does not consume it (for example kvm)
• feature:n → requires this feature and consumes n of it

Describe alternatives you've considered

Doing nothing and have Hydra balance its builders on build slots only.

Additional context
Clone of #2307
cc @ajs124 @LisannaAtHome

[toraritte]

Related: NixOS/hydra issue #588: Consumable system features

[thufschmitt]

I really like the idea of making the remote build scheduler more flexible. I wonder whether it could be worth looking at the prior art (Bazel’s remote build protocol in particular as it seems to become some kind of a standard for build-systems), and maybe try to align with it