[Bio-packaging] Using a shared Guix store (was RE: testing out guix)

[Ricardo Wurmus]

Cook, Malcolm <MEC at stowers.org> writes:

> Can anyone elaborate a little on what are the obstacles to having
> `/gnu` mounted read-write network wide?

Yes, the primary problem is that the daemon assumes that it is the only
thing writing to the store and the localstatedir.  Any modification of
profiles and the store goes through the daemon.

> If so, might this be mitigated using a variant off of "Using the
> Offload Facility"
> (http://www.gnu.org/software/guix/manual/guix.html#Daemon-Offload-Setup)
> in which builds would still be offloaded (and thus subject to
> coordination), with the elimination of the need for " Missing
> prerequisites for the build are copied over SSH to the target machine,
> which then proceeds with the build; upon success the output(s) of the
> build are copied back to the initial machine" since they would be done
> through the shared file system?

Something like that has been suggested before: if the daemon were to
accept authenticated connections from the outside rather than to just
listen on a local socket we could have remote guix clients connecting to
the central daemon.

> Do I understand correctly that in your setup, Ricardo, that absolutely
> no `guix` commands are executed on any host other than the "single
> dedicated server".  What about `guix environment p1 p2 p3` when p1 p2
> p3 are already available in /gnu.  If I understand correctly, in such
> a case, nothing need be written to /gnu... and so should not present
> any challenge to running guix off a shared mount.  Or am I missing an
> aspect of what is going on?

This is correct.  Our needs are rather simple, so people don’t use any
of the guix commands on their local machines, nor on the cluster nodes.
This is not as inconvenient as this may seem when profiles don’t change
often, but it is of course a serious limitation.  My first goal was to
replace traditional software *packaging* (because that’s what affected
my work as a sysadmin); the next goal is to allow users to conveniently
perform software *management*.  At the moment this requires users to log
on to the guix management host (or to ask a sysadmin to perform the
changes for them).

Currently our users are okay with that, probably to a large part because
they are not yet aware of all the features of Guix.  They are only used
to management by sysadmins or manual compilation, so they are not
inconvenienced.

Ultimately, the correct fix is to allow remote guix clients to
communicate with a central guix daemon.  The daemon does not even need
to be aware of remote connections if guix clients can transparently
connect via SSH and send RPCs to the socket.  This is not yet
implemented.

Even then, /gnu would be mounted read-only on all but the management
host, because there would still only be one daemon writing to the store
and the localstatedir – even if it would take requests from multiple
remote guix clients.

~~ Ricardo