Respect if a substitute does not understand/provide the `realisations` endpoint

[NobbZ]

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

I have several substitutes in my configuration and those are shared across all my machines automatically.

One of my machines is partially build on content addressed derivations, and this machine is hitting all the substitutes realisations endpoints, or trying to at least.

This takes a lot of time.

Describe the solution you'd like

Automatic discovery whether or not a substitute does support the realisations endpoint, and not wasting much time polling it.

Alternatively a configuration option that would distinguish between regular and CA substitutes.

Describe alternatives you've considered

Rewrite my config to not fully share the substitutes across machines but selectively. Still this would lead to not having access to my non-CA emacs builds on the partial CA host.

[thufschmitt]

One of my machines is partially build on content addressed derivations, and this machine is hitting all the substitutes
realisations endpoints, or trying to at least.

This takes a lot of time.

That’s strange, that shouldn’t take more time than a regular cache trying to hit the narinfos (does your Nix version contain #4781 ?).

(Also, the current implementation doesn’t try to fetch the realisations at all for strictly input-addressed derivations, but I guess your issue is more about the fact that building a CA derivation will try to hit cache.nixos.org although you know that it won’t have any realisation).

Automatic discovery whether or not a substitute does support the realisations endpoint, and not wasting much time polling it.

I don’t think we can do that without breaking the existing ca-aware caches. Maybe we could add this to the cache-info file, but I’m not sure how much sense that will make in the long run if CA becomes more mainstream

Alternatively a configuration option that would distinguish between regular and CA substitutes.

That bit could work better, yes (although I’d rather have the substitution just be fast-enough that it doesn’t matter)

[NobbZ]

I'm using nix from master, so I assume the nix I'm using has that fix (a build from last wednesday IIRC).

The problem is, nix is asking 5 hosts for a realisation. Of course this takes a lot longer than just asking a single host for it. Especially as this seems still not beeing parallelized or even reusing connections.

The 3 cachix entries I use, do not even know how to properly respond to requests to the realisation endpoint. Asking them is a waste of time.

Of course when its just about a handfull of packages, this is neglectible, though if I indeed try this for the full system, ~4k realisations have to been asked for. That are 20k requests, of which I know in advance that ~12k of them are just a waste of time.

From that machine it is a difference of ~4 Minutes just to collect the initial set of realisations before starting any builds with the 3 cachix caches enabled vs having them disabled.

[michaelpj]

Perhaps you would also benefit from #3019.

[domenkozar]

Could be a field in /nix-cache-info to say if CA is supported or not without guessing.

[stale]

I marked this as stale due to inactivity. → More info