Singularity is witnessing heavy adoption from a classification of users interested in AI, Deep Learning, compute-driven-analytics, and even IoT. Characterized as “Enterprise Performance Computing” (EPC), these containerized workflows allow scientists and researchers to easily access the latest tools and technologies across the variety of on-prem and cloud service provider offerings. Because of this, the growing analytics demand is not only driving change in traditional HPC centers, but is also influencing classic enterprise infrastructures.
The need for “analytics ready” computing resources have scientists, and their counterparts looking toward cloud native solutions to satisfy the varying enterprise performance computing workloads. According to the Cloud Native Computing Foundation (CNCF) a Cloud Native strategy is about scale and resilience: “distributed systems capable of scaling to tens of thousands of self healing multi-tenant nodes”. In order to leverage these resources, users have adopted linux containers as a defacto solution.
The Open Container Initiative (OCI), created by the Linux Foundation, is designed to allow for portability and compliance across all major, operating systems and platforms without introducing barriers. The OCI specification, in our view, paves the way toward two main features that science requires, reproducibility and standardization.
At Sylabs, we want to reduce barriers for scientists, and the curious, to gain access to tools and workflows for pure exploration of knowledge. The Singularity container platform, has features like native GPU and InfiniBand integration that make it a container solution for that exploration. To that extent, we’re announcing intent to provide a runtime implementation of the current OCI spec.
Currently, the OCI runtime-spec specifies two things:
- The image format
- A runtime configuration; specified as a JSON file (config.json)
- The Runtime specifies 5 must-have API calls:
- Query state
By introducing an OCI compliant runtime, Singularity will now be officially compatible with popular container orchestration tools such as Kubernetes (via CRI). To those of you that prefer the current Singularity interface, using the OCI compliant version of the Singularity runtime is completely optional.
We’re still figuring out the best way to let users choose, as there are many challenges on mapping concepts from the OCI runtime-spec into the singularity runtime. One of the questions we have is, should the OCI version be a separate package, turned on via command line flag, or something completely different?
Let us know what you think →