Note: This documentation is very basic and needs improvement!
Here’s an example configuration file:
This provides the user with no opportunity to select a specific image. Here are some changes to the above example to allow the user to specify an image path:
Then, users could add the following to their submit file (note the quoting):
Finally, let’s pick an image based on the OS – not the filename:
Then, the user adds to their submit file:
That would cause the job to run on the native host for CentOS6 hosts and inside a CentOS6 Singularity container on CentOS7 hosts.
By default, singularity will bind mount the scratch directory that contains transfered input files, working files, and other per-job information into the container. The administrator can optionally specific additional directories to be bind mounted into the container. For example, if there is some common shared input data located on a machine, or on a shared filesystem, this directory can be bind-mounted and be visible inside the container. This is controlled by the configuration parameter SINGULARITY_BIND_EXPR. This is an expression, which is evaluated in the context of the machine and job ads, and which should evaluated to a string which contains a space separated list of directories to mount.
So, to always bind mount a directory named /nfs into the image, and administrator could set
Or, if a trusted user is allowed to bind mount anything on the host, an expression could be
Finally, if an administrator wants to pass additional arguments to the singularity exec command that HTCondor does not currently support, the parameter SINGULARITY_EXTRA_ARGUMENTS allows arbitraty additional parameters to be passed to the singularity exec command. For example, to pass the –nv argument, to allow the GPUs on the host to be visible inside the container, an administrator could set
If Singularity is installed as non-setuid, the following flag must be set for condor_ssh_to_job to work.