Prepare, validate, build, and use Nemotron Customizer airgap image bundles for offline clusters. Use when planning airgapped deployments, editing deploy/nemotron-customizer/airgap/airgap.yaml, selecting workflow targets, grouping step execution images, baking repo overlays or wheel additions, resuming airgap runner builds, or submitting `nemotron steps run` jobs inside an airgapped environment.
80
100%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Low
Low-risk findings worth noting
Use this skill to help an agent produce a connected-machine airgap bundle and then submit Nemotron Customizer steps from the airgapped side. Keep it grounded in the checked-in runner and manifests; do not invent a parallel packaging flow.
deploy/nemotron-customizer/airgap/README.md for the operator flow.deploy/nemotron-customizer/airgap/airgap.yaml for the current image map.deploy/nemotron-customizer/airgap/runner.py when changing behavior.tests/deploy/test_airgap_runner.py before editing runner logic.deploy/nemotron-customizer/airgap/configs/ for runtime overlay configs.For selected steps, inspect the catalog through the CLI:
uv run nemotron steps show <step_id> --jsonEstablish the side of the workflow:
Gather the minimum inputs:
sft/megatron_bridge:tiny.linux/amd64.--execute, Docker build,
Docker volume cleanup, or state-file removal are explicitly allowed.Plan with the runner first:
uv run python deploy/nemotron-customizer/airgap/runner.py \
--config deploy/nemotron-customizer/airgap/airgap.yamlUse --target <step_id>:<config> for one-off selections without editing YAML.
The runner expands dependencies from dependencies, validates selected step
files/configs, groups execution images, and prints selected execution images.
Edit airgap.yaml only where the runner expects configuration:
workflow.stages or CLI --target for selected customer steps.dependencies for explicit upstream Nemotron Customizer step outputs.step_execution_images for step-to-image mapping.execution_images for base image, tag, tar, platform, and import probes.launcher_image for the launcher container.Execute only when the user asks for a real build:
uv run python deploy/nemotron-customizer/airgap/runner.py \
--config deploy/nemotron-customizer/airgap/airgap.yaml \
--executeIf a build fails midway, keep airgap-build-state.yaml and rerun the same
command. Remove or move that state only when intentionally changing the plan.
out/airgap-manifest.yaml under
step_execution_images. Submit with the plural CLI:uv run nemotron steps run <step_id> \
-c <config-or-airgap-overlay> \
-b <airgap-profile> \
run.env.container_image=<image-from-manifest>For sft/megatron_bridge, prefer the airgap overlay configs under
deploy/nemotron-customizer/airgap/configs/; they clear runtime git auto-mounts
because the runner bakes those repos into the execution image.
run.env.mounts.${auto_mount:git+...} as a connected-machine build input. The runner
bakes pinned repo overlays into execution images so airgapped jobs do not clone
from GitHub.discover-execution-deps and
import probes determine small additions; keep heavyweight framework deps in
the base image choice.HF_HUB_OFFLINE=1, TRANSFORMERS_OFFLINE=1, HF_DATASETS_OFFLINE=1,
and WANDB_MODE=offline.nemotron steps ...; do not reintroduce nemotron step ....After edits to runner logic, YAML structure, or airgap docs, run:
uv run pytest tests/deploy/test_airgap_runner.py -qFor CLI-facing examples, also smoke the command shape:
uv run nemotron steps --help
uv run nemotron steps show data_prep/sft_packing --jsonDo not run Docker build/save stages during validation unless the user explicitly asked for a real connected-machine bundle build.
5277655
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.