1 of 5

Project Tapis: Containers

1

Steve Black, PhD

Cloud and Interactive Computing

Texas Advanced Computing Center

University of Texas, Austin

2 of 5

Project Tapis: Containers

  • In general HPC lags behind industry in adopting containers
  • A major impediment is lack of standards for application invocation
  • Some HPC specific needs not readily incorporated into a container image. For example:
    • MPI launchers, job schedulers.
    • Specialized hardware such as GPUs, networking fabrics
    • System specific tools such as container runtimes or custom workflow managers
  • Use of containers in Tapis v3 is very much a work in progress

3 of 5

Tapis Approach

  • Increase portability and reproducibility by treating containers as first class objects, especially within the applications and jobs subsystems.
  • Allow execution system definitions to include capabilities which are specified as requirements by application authors.
  • Framework can then match an application execution (a job) with any system that meets the requirements.
  • This allows for prioritizing job execution in order to optimize for goals such as minimizing time-to-solution or cost.

4 of 5

Tapis Approach

  • Formalize the process of invoking a containerized application
  • Leverage emerging standards, such as Common Workflow Language (CWL), to determine an application’s invocation process
  • Integrate with third party image registries such as:
    • Docker Hub
    • BioContainers
    • Singularity Hub

5 of 5

Execution System Capabilities

  • Initially several categories of capabilities identified
    • Container Runtime - including type, version, optional features (such as bind mounts for Singularity)
    • Scheduler - type (Slurm, PBS, etc) and version
    • MPI - version, network
    • Hardware - CPU, GPU, NodeCount, MemoryPerNode, etc

​