ganga.GangaCore.Lib.Virtualization.Singularity module

The Singularity class can be used for either Singularity or Docker images. It requires that singularity is installed on the worker node.

For Singularity images you provide the image name and tag from Singularity hub like

j=Job() j.application=Executable(exe=File(‘my/full/path/to/executable’)) j.virtualization = Singularity(“shub://image:tag”)

Notice how the executable is given as a File object. This ensures that it is copied to the working directory and thus will be accessible inside the container.

The container can also be provided as a Docker image from a repository. The default repository is Docker hub.

j.virtualization = Singularity(“docker://gitlab-registry.cern.ch/lhcb-core/lbdocker/centos7-build:v3”)

j.virtualization = Singularity(“docker://fedora:latest”)

Another option is to provide a GangaFile Object which points to a singularity file. In that case the singularity image file will be copied to the worker node. The first example is with an image located on some shared disk. This will be effective for running on a local backend or a batch system with a shared disk system.

imagefile = SharedFile(‘myimage.sif’, locations=[‘/my/full/path/myimage.sif’]) j.virtualization = Singularity(image= imagefile)

while a second example is with an image located in the Dirac Storage Element. This will be effective when using the Dirac backend.

imagefile = DiracFile(‘myimage.sif’, lfn=[‘/some/lfn/path’]) j.virtualization = Singularity(image= imagefile)

If the image is a private image, the username and password of the deploy token can be given like the example below. Look inside Gitlab setting for how to set this up. The token will only need access to the images and nothing else.

j.virtualization.tokenuser = ‘gitlab+deploy-token-123’ j.virtualization.tokenpassword = ‘gftrh84dgel-245^ghHH’

Directories can be mounted from the host to the container using key-value pairs to the mounts option. If the directory is not available on the host, a warning will be written to stderr of the job and no mount will be attempted.

j.virtualization.mounts = {‘/cvmfs’:’/cvmfs’}

By default the container is started in singularity with the –nohome option. Extra options can be provided through the options attribute. See the Singularity documentation for what is possible.

If the singularity binary is not available in the PATH on the remote node - or has a different name, it is possible to give the name of it like

j.virtualization.binary=’/cvmfs/oasis.opensciencegrid.org/mis/singularity/current/bin/singularity’

ganga.GangaCore.Lib.Virtualization.Singularity.const_lock

This is a context manager which acquires the const write lock on the object’s root object.

This lock acquires exclusive access over an object tree to prevent it from changing. Reading schema attributes on the object is still allowed but changing them is not. Only one thread can hold this lock at once.