From: "Cook, Malcolm" <MEC@stowers.org>
To: 'Ricardo Wurmus' <ricardo.wurmus@mdc-berlin.de>
Cc: Guix-devel <guix-devel@gnu.org>,
'Pjotr Prins' <pjotr.public66@thebird.nl>,
"'bio-packaging@mailman.open-bio.org'"
<bio-packaging@mailman.open-bio.org>
Subject: RE: Using a shared Guix store (was RE: [Bio-packaging] testing out guix)
Date: Fri, 19 Jun 2015 17:48:55 +0000 [thread overview]
Message-ID: <3784bfce22f4406f8ee2d3affda0474c@exchsrv2.sgc.loc> (raw)
In-Reply-To: <877fr0i0kl.fsf@mdc-berlin.de>
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
next prev parent reply other threads:[~2015-06-19 17:49 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-18 20:22 Using a shared Guix store (was RE: [Bio-packaging] testing out guix) Cook, Malcolm
2015-06-19 8:06 ` Ricardo Wurmus
2015-06-19 11:34 ` Ludovic Courtès
2015-06-25 6:40 ` Ricardo Wurmus
2015-06-19 11:40 ` Ludovic Courtès
2015-07-08 19:20 ` Cook, Malcolm
2015-07-08 19:43 ` Ricardo Wurmus
2015-06-19 17:48 ` Cook, Malcolm [this message]
2015-06-24 19:57 ` Ludovic Courtès
2015-07-08 18:03 ` Cook, Malcolm
2015-07-08 19:53 ` Ricardo Wurmus
2015-07-10 8:39 ` Ludovic Courtès
2015-07-11 0:48 ` Cook, Malcolm
2015-07-13 16:45 ` Test suite failures Ludovic Courtès
2015-07-18 3:04 ` Cook, Malcolm
2015-07-18 15:02 ` Ludovic Courtès
2015-07-11 0:54 ` Using a shared Guix store (was RE: [Bio-packaging] testing out guix) Cook, Malcolm
2015-07-15 15:45 ` Ricardo Wurmus
2015-07-15 19:49 ` Cook, Malcolm
2015-07-15 20:28 ` Pjotr Prins
2015-07-18 9:26 ` Cook, Malcolm
2015-07-18 15:13 ` Ludovic Courtès
2015-07-19 9:18 ` Claes Wallin (韋嘉誠)
2015-07-19 9:33 ` Andreas Enge
2015-07-20 22:37 ` Cook, Malcolm
2015-07-21 20:23 ` Cook, Malcolm
2015-07-21 20:29 ` Ricardo Wurmus
2015-07-23 22:52 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3784bfce22f4406f8ee2d3affda0474c@exchsrv2.sgc.loc \
--to=mec@stowers.org \
--cc=bio-packaging@mailman.open-bio.org \
--cc=guix-devel@gnu.org \
--cc=pjotr.public66@thebird.nl \
--cc=ricardo.wurmus@mdc-berlin.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.