[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ~/.config/guix/current
From: |
Ludovic Courtès |
Subject: |
Re: ~/.config/guix/current |
Date: |
Thu, 12 Jul 2018 10:26:53 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Hello Mikhail,
Mikhail Kryshen <address@hidden> skribis:
> Ludovic Courtès <address@hidden> writes:
>
>>> a) master node running guix-daemon [1]
>>> - will "guix gc" destroy guix/current profiles if /home is not
>>> mounted on the master node? What if some users have local
>>> home directories and some are on nfs?
>>
>>> [1]
>>> https://guix-hpc.bordeaux.inria.fr/blog/2017/11/installing-guix-on-a-cluster/
>>
>> This is what I would recommend, and as the post suggests, you’ll have to
>> make sure home directories are visible to guix-daemon, which means
>> having them mounted on the master node.
>>
>> If you don’t do that, there’s a risk that user-pulled Guixes will be
>> reclaimed prematurely, simply because the GC won’t see that they are
>> still “live.”
>
> But ~root is local on each machine, so root-pulled Guix will still not
> be protected from gc.
True, but in this configuration, only the root account of the master
node really matters, and it’s protected from GC.
> Btw, is option a) possible on GuixSD?
I think so. Why wouldn’t it?
>>> b) guix-daemon on every computer
>>> - then /gnu/store and /var/guix/profiles will by local and user
>>> profiles can be different on every computer, but
>>> ~/.config/guix/current will link to nonexistent store item if
>>> "guix pull" was invoked by the same user on a different machine.
>>
>> If this is a cluster, I would definitely recommend option a), which
>> provides a single world view, shared storage, etc.
>
> It's for GNU/Linux workstations in university labs. I want to use Guix
> to provide additional software that is not available in required
> configuration in the host distro, and also give students an interesting
> environment to experiment.
>
> I decided for now to go with the option b) for performance and
> reliability. My previous attempts to deploy large software packages on
> NFS (even with FS-Cache enabled) didn't work well. Also, it may be
> possible to somehow exploit immutability of the store items to share and
> cache them more efficiently.
Yes, we use option a) on a cluster at Inria (and Roel and Ricardo have a
similar setup at their institutes), and it works pretty well.
>From a performance viewpoint, it’s important for the master node to have
the store on a local file system, so that things like GC and
deduplication run quickly enough—these would be slow over NFS. For the
compute nodes, accessing packages over NFS is good enough.
> The computers periodically run "guix pull" as root and I want to make
> the updated Guix automatically available to all users, but
> /usr/local/bin/guix can't be linked to
> /root/.config/guix/current/bin/guix as the /root directory is normally
> not searchable by other users — another reason to keep pulled Guix
> profiles in /var. I workaround this by having the script that runs
> "guix pull" to symlink /usr/local/bin/guix directly into the new profile
> in /gnu/store.
I see. I’ll look into treating ~/.config/guix/current similarly to
~/.guix-profile. That would help for a setup like yours.
>> I agree it would be useful (the way we do it on GuixSD is by having
>> /etc/profile define INFOPATH systematically, for instance), but there’s
>> no clear way to have ~/.config/guix/current/etc/profile define them
>> directly.
>
> It would be useful to have a similar script included in the guix package
> to be symlinked into host distro's /etc/profile.d
We could do that, though it wouldn’t help much: you’d have to add one
line to /etc/profile instead of adding two lines, essentially.
Thanks,
Ludo’.