Re: “guix gc”, auto gcroots, cluster deployments

["Ludovic Courtès" <ludo@gnu.org>]

Hello!

Ricardo Wurmus <rekado@elephly.net> skribis:

>> Would it be possible to add an option to retrospectively apply this
>> transformation?  Maybe that could work somewhat like this:
>>
>> $ ls -lha
>> ... /home/me/projects/mrg1_chipseq/.guix-profile-1-link ->
>> /gnu/store/ap0vrfxjdj57iqdapg8q83l4f7aylqzm-profile
>
> This wouldn’t work, because we can’t read
> /home/me/projects/mrg1_chipseq/.guix-profile-1-link centrally.  In 
> this particular case only the user “me” could resolve the link and
> thus migrate the link.  (I would do this semi-manually by 
> impersonating the users to read their links.)
>
> ~ ~ ~
>
> Another related problem I found is that the names of the links in
> unreadable space may have names that only make sense on the system 
> where they were created.  For example, on the server “beast” we may
> mount the cluster home directory as “/clusterhome/me”, whereas on
> cluster nodes it would be mounted as “/home/me”.  When I have Guix
> record a gcroot while working on “beast” I would get a link that is no
> longer valid when I work on the cluster.

To me these are “documented limitations”.  User home directories must be
visible to the head node where guix-daemon runs, or GC won’t see all the
roots.  It seems hard to avoid.  Though an admin could decide that only
~/.guix-profile matters, and in that case the head node only needs to be
able to access /var/guix/profiles (a restriction that may be acceptable
in practice: users need to restrict themselves to ~/.guix-profile and
‘guix environment’).

But yeah, I agree these are gotchas and it’s easy for a cluster admin to
shoot themself in the foot.

Thoughts?

Ludo’.