Re: Guix on clusters and in HPC

[Ricardo Wurmus]

myglc2 <address@hidden> writes:

> On 10/26/2016 at 14:08 Ricardo Wurmus writes:
>
>> At the MDC we’re using SGE and users specify their software environment
>> in the job script.  The software environment is a Guix profile, so the
>> job script usually contains a line to source the profile’s
>> “etc/profile”, which has the effect of setting up the required
>> environment variables.
>
> Cool. How do you deal with the tendency of user's profiles to be "moving
> targets?" IOW, I am wondering how one would reproduce a result at a
> later date when one's profile has "changed"?

I strongly encourage users to do two things:

- use manifests
- record the current version of Guix and our local package repository
  when instantiating a manifest.  It only takes these two pieces of
  information to reproduce a software environment

>>> Based on my experiments with Guix/Debian, GuixSD, VMs, and VM images it
>>> is not obvious to me which of these levels of abstraction is
>>> appropriate.
>>
>> FWIW we’re using Guix on top of CentOS 6.8.  The store is mounted
>> read-only on all cluster nodes.
>
> Nice. Do you attempt to "protect" your users from variations in the
> CentOS config?

I’m not sure I understand the question.  With Guix we’re not relying on
the host system software with the exception of the kernel at runtime.
Users have one profile that they use on the cluster nodes (running
CentOS) as well as on their workstations (Ubuntu or a later version of
CentOS).

When it comes to building software outside of Guix (e.g. when using “pip
install” for Python or “install.packages()” in R) there’s little I can
do.  I’m considering to provide a “runtime” environment in which the
Guix toolchain and very common libraries are available, which can be
used to build software in a traditional fashion.  I’m hacking on Rstudio
server now to make it usable running inside a container where the system
toolchain is essentially swapped out for a toolchain from Guix.

This is needed because mixing binaries that are dynamically loaded at
runtime (e.g. some R modules from Guix with bindings to system
libraries) cannot possibly work due to ABI incompatibility.  This is
actually the most common problem I’m facing here, because users are used
to install stuff on their own.  Mixing with Guix binaries only works as
long as the applications run as separate processes.

~~ Ricardo