You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SingularityCE 3.9 was released in November 2021. The historic roadmap items that were included in 3.9 are below. Other smaller changes are reflected in the CHANGELOG.md for the project
NVIDIA GPU / CUDA support via upstream tooling Feature: NVIDIA_VISIBLE_DEVICES support #73
SingularityCE uses its own code to bind basic NVIDIA driver/CUDA libraries into a running container. This works well, but does not support features such as GPU masking, MIG awareness, that users of docker and the nvidia docker runtime have become accustomed to. It's proposed to switch to libnvidia-container for GPU setup to support these features, with the existing pathway as a fall-back.Experimental addition for 3.9 merged to master.
'Docker-like' mode ’Docker-like’ mode #75
By default, SingularityCE runs containers far less isolated from the host than Docker - relying on system restrictions on the user. This is very convenient for traditional HPC-like jobs, but some Docker containers can have conflicts with files and other things that enter the container from the host. We have a number of flags such as --contain to work around this, but it's often unclear which are needed. A shortcut to apply the most 'docker-like', but practical configuration would be useful.--compat flag merged to master for 3.9
--mount Option (Initial Bind Support) Long form --mount to support special chars in bind mount paths etc. #118
It is not possible to use a ':' or ',' in a bind path via -B etc. Providing an escaping mechanism is a work-around. However, implementing a long-form --mount syntax, which is how Docker handles the issue, has compatibility and clarity benefits.Included for 3.9
Unify external binary finding Unify finding external binaries on PATH / from config #178
We use various external binaries, and it's not always obvious how we find then. Some can be explicitly specified in singularity.conf, some cannot. This causes special problems for systems managed with a minimal base, and even common tools provided through module / Nix / Guix / Conda environments. System administrators in restrictive environment may also want to ensure every host binary called by SingularityCE can be enforced to be a specified exectuable.Merged to master for 3.9
cgroups v2 support cgroups v2 support #60
Provide initial support for cgroups v2 unified hierarchy.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
3.9 Features
SingularityCE 3.9 was released in November 2021. The historic roadmap items that were included in 3.9 are below. Other smaller changes are reflected in the CHANGELOG.md for the project
NVIDIA GPU / CUDA support via upstream toolingExperimental addition for 3.9 merged to master.Feature: NVIDIA_VISIBLE_DEVICES support #73
SingularityCE uses its own code to bind basic NVIDIA driver/CUDA libraries into a running container. This works well, but does not support features such as GPU masking, MIG awareness, that users of docker and the nvidia docker runtime have become accustomed to. It's proposed to switch to libnvidia-container for GPU setup to support these features, with the existing pathway as a fall-back.
'Docker-like' mode’Docker-like’ mode #75
By default, SingularityCE runs containers far less isolated from the host than Docker - relying on system restrictions on the user. This is very convenient for traditional HPC-like jobs, but some Docker containers can have conflicts with files and other things that enter the container from the host. We have a number of flags such as
--contain
to work around this, but it's often unclear which are needed. A shortcut to apply the most 'docker-like', but practical configuration would be useful.--compat
flag merged to master for 3.9Included for 3.9--mount
Option (Initial Bind Support)Long form --mount to support special chars in bind mount paths etc. #118
It is not possible to use a ':' or ',' in a bind path via
-B
etc. Providing an escaping mechanism is a work-around. However, implementing a long-form--mount
syntax, which is how Docker handles the issue, has compatibility and clarity benefits.Unify external binary findingMerged to master for 3.9Unify finding external binaries on PATH / from config #178
We use various external binaries, and it's not always obvious how we find then. Some can be explicitly specified in
singularity.conf
, some cannot. This causes special problems for systems managed with a minimal base, and even common tools provided through module / Nix / Guix / Conda environments. System administrators in restrictive environment may also want to ensure every host binary called by SingularityCE can be enforced to be a specified exectuable.cgroups v2 supportcgroups v2 support #60
Provide initial support for cgroups v2 unified hierarchy.
Beta Was this translation helpful? Give feedback.
All reactions