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

[Cook, Malcolm]

Ricardo,

Thanks for your complete and easy-to-understand response to my inquiries.

> > 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-
> Setu
> > p) 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.

Hmm.  So, for now, I could just teach users to, i.e., `ssh ${USER}@${GUIX_HOST}   /path/to/guix package -r lua -i guile guile-cairo` and contrive for GUIX_HOST to be defined for them.

Or, wrap it up even further, and contrive for everyone to have the following in their env:

	alias guixpkg='ssh ${USER}@${GUIX_HOST} /path/to/guix package'

??

> > 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).

I totally get your priorities.  Thanks for the reveal!  Are these also the priorities of the GnuSD project, do you know?

> 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.

Sounds great.  On the roadmap?

> 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.

Agreed.  

Fingers crossed, and thanks again,

~Malcolm


> 
> ~~ Ricardo