NVIDIA-NeMo / NVIDIA-NeMo/DataDesigner

Build, inspect, and manage SQSH images for Slurm

Open
#867 0 comments 0 reactions 1 assignee View on GitHub

@nabinchha is already working on this.

Since Aug 15, 2026.

task
Dominant language
Python
Stars
2.2k
Forks
211
Avg merge
2d 6h
Merged PRs (30d)
40

Description

Priority Level

High

Task Summary

Implement the optional Slurm package's lifecycle for importing OCI images, inspecting SQSH artifacts, registering immutable image facts, and resolving client and serving images for run planning.

Technical Details & Implementation Plan
  • Define and consume the typed image-build request and versioned inspection record.
  • Submit OCI import/conversion and existing-SQSH inspection through the configured CPU-capable Slurm partition.
  • Publish temporary build output only after checksum, kind, and inspection validation succeeds.
  • Record the source OCI digest separately from the resulting SQSH SHA-256.
  • Inspect client images for Python implementation/version/ABI, installed distributions, Data Designer version, and the required dependency installer.
  • Inspect serving images for server type, runtime version, and executable path.
  • Maintain an atomic alias/path registry beneath the selected workspace with per-target locking.
  • Register an existing absolute compute-visible SQSH in place without copying it.
  • Resolve both alias and registered-path references to immutable path, digest, and factual inspection metadata.
  • Unregister aliases without deleting underlying artifacts.
Acceptance criteria
  • OCI import and existing-SQSH registration both produce digest-bound inspection records.
  • Failed import, inspection, checksum, kind, collision, or publication leaves no usable alias or partial final artifact.
  • Generation planning rejects missing, unregistered, modified, kind-mismatched, unsupported, or incompatible images.
  • Concurrent writers cannot publish conflicting aliases or artifacts.
  • Client and serving inspection fixtures cover supported and rejected metadata.
  • Image operations derive mutable storage from the selected workspace and do not depend on the current directory or installation path.
Out of scope
  • Automatic image building during generation.
  • Artifact garbage collection.
  • Mutable capability claims supplied by users.
  • General container-orchestration or image-distribution APIs.
Investigation / Context

This is the image-management lane for #850. Generation runs select already inspected images and pin their immutable facts before submission.

Agent Plan / Findings

Implement the image service, registry, factual inspectors, CPU build plan, locking, and failure cleanup as focused slices that share the common batch renderer and scheduler client.

Planned PR slices
  1. Inspection and registry foundation

    • Status: Incomplete — PR #891
    • Implement package-owned client and serving inspectors.
    • Implement immutable image facts, alias/path resolution, registry locking, and registry operations against deterministic fakes.
    • This slice may proceed alongside #868.
  2. CPU Slurm image lifecycle

    • Status: Incomplete — PR not opened
    • Implement structured OCI import and existing-SQSH inspection plans.
    • Submit work through the command-client and renderer primitives from #868.
    • This slice provides the image lifecycle needed for the M1 proof.
  3. Publication and failure hardening

    • Status: Incomplete — PR not opened
    • Add atomic artifact and metadata publication, collision handling, concurrency coverage, and failure cleanup.
    • Complete compatibility rejection and multi-image fixtures.
    • This slice completes the issue and its acceptance criteria.

Each slice is an independently reviewable PR against feat/slurm-execution. Intermediate PRs reference Part of #867; only the final PR uses Closes #867.

Dependencies

Blocked by the shared-contract and fake-infrastructure foundation work tracked by #850.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.