Oh right yes very true, in fact you told me that a while back and it slipped my mind. I meant to do some experiments today but ran out of time, I’ll try next week. The reason for the experiments would be to find out if the remote store way will have to copy the complete transitive dependencies of the drvs. If it turns out the answer is yes, would that not be a problem? If it’s no, I guess that would mean that either they don’t wind up in /nix/store, or my assumption that presence in /nix/store requires the presence of the dependencies, is wrong.
Wouldn’t it have been simpler to allow drvs to be copied without their dependents?
Yes! The “closure property” is currently interpreted way to strictly, and is thus incompatible with “lazy paging” of many sorts.
For anything that is content-addressed recursively (which should be everything, even if the store path is an input-address) we can lazily crawl the graph without loss of security.
We just released yensid, which solves quite a few but not all of the problems @elaforge mentioned in the original post. It’s quite simple - an SSH proxy with an optional CA. It can’t do anything that needs to peek into the actual contents of the communication, but that’s enough to:
- Do global load balancing
- Handle (IP-based) affinity
- Manage dynamic lists of remote builders
- Use other data (such as CPU usage or memory) for load balancing
elaforge’s work is definitely more mature and capable, but if you’re looking for something simple that you can deploy in a day and will still give you improvements over vanilla nix builds, it could be useful!
3 Likes