Mathieu Othacehe <othacehe@gnu.org> writes:

>> I imagine the daemon could be structured as a set of actors (it’s really
>> my thing these days ;-)), with an eye on facilitating code sharing and
>> interaction with the Coordinator, Cuirass, and all that.
>
> I think this point is really important here. If the offload mechanism of
> the existing guix-daemon was scaling correctly, with a better API, we
> would probably never had to develop the Cuirass remote worker and the
> Build Coordinator mechanisms.

Indeed.

> Perhaps, part of the Build Coordinator code could be one day integrated
> inside the new guix-daemon so that we can only use one offload mechanism
> for all use cases. Users of the current "guix offload" as well as CI
> tools could rely upon a unique offload mechanism.

Yeah, I think the ideal situation would be to have a daemon that's
flexible and extensible enough to allow this, without being too
complicated or fragile.

> The three other points I had in mind when proposing the subject to NLNet
> were to:
>
> - Fix the sqlite contention issues that have been observed on Berlin and
>   other machines with huge local databases.

Yeah, I think there's some simple things that can be done to improve the
use of SQLite, and then some instrumentation can be added so that any
performance issues can be better understood.

> - Remove the GC lock: I think it has been done on recent nix-daemon.

I'm hoping that with some careful design of how to do garbage
collection, this should be possible.

> - Add support for unprivileged daemon.

I'm not quite sure what is required for this, but maybe it would be
possible without too much effort.

Thanks for your input!

Chris