Launcher reference

A worker (Kronos or Gaia) is a long-lived controller that never runs a compile or evaluation in its own process. For each task it receives, it launches the actual work in a fresh, isolated container and tears it down afterward. This keeps every task hermetic — its own filesystem, GPU allocation, and lifetime — and lets one controller serve task after task without state leaking between them.

How that task container is created depends on where the worker runs:

• On a Docker host (the Kronos workers Docker flow) — the worker asks the host's Docker daemon to run a sibling container from the same worker image, then streams the job into it. A host-wide slot (a fixed container name) serializes tasks so two workers on the same box never contend for the GPU at once.
• On Kubernetes (the Deploy with Helm flow) — the worker creates one Kubernetes Job per task from a Job template, and waits for it to finish. The Job pod carries all the hardware targeting (GPU request, node selector, tolerations, runtime class).

In both cases the worker fills in the task container's image, command, and arguments itself; everything else about that container is what you configure below.

Task container settings on a Docker host

On a Docker-host deployment, the per-task container is shaped by environment variables set on the worker container (see the Kronos / Gaia worker pages). Each maps to a Docker run setting; omit one and the daemon's default applies.

Variable	Effect on each task container
YASP_LAUNCH_WORKER_IMAGE	The image each task runs in. Must match the worker's own image.
YASP_LAUNCH_DOCKER_HOST	Docker daemon URL the worker talks to (e.g. unix:///var/run/docker.sock). Its presence is also what makes the worker use the Docker host path.
YASP_LAUNCH_DOCKER_GPUS	GPU exposure: all, device=<id>[,<id>…], or an integer count. Use on dGPU hosts.
YASP_LAUNCH_DOCKER_RUNTIME	Container runtime (e.g. nvidia). Required on Jetson / Drive AGX, whose toolkit runs in csv mode and rejects the GPU flag — pair it with NVIDIA_VISIBLE_DEVICES in the container env instead of …_GPUS.
YASP_LAUNCH_DOCKER_SHM_SIZE	Shared-memory size (e.g. 8g).
YASP_LAUNCH_DOCKER_NETWORK	Network mode (e.g. host, a named network). host is required on veth-less hosts (Drive AGX).
YASP_LAUNCH_DOCKER_MEMORY	Memory limit (e.g. 16g).
YASP_LAUNCH_DOCKER_CPUS	CPU limit (fractional cores).
YASP_LAUNCH_DOCKER_VOLUMES	Comma-separated src:dst[:mode] mounts (default mode rw). Used for the dataset cache.
YASP_LAUNCH_DOCKER_DEVICES	Comma-separated host:container[:perms] device mappings (e.g. ROCm /dev/kfd, /dev/dri).
YASP_LAUNCH_DOCKER_CAP_ADD / …_CAP_DROP	Linux capabilities to add / drop.
YASP_LAUNCH_DOCKER_ULIMITS	Comma-separated name=soft[:hard] ulimits.
YASP_LAUNCH_DOCKER_SECURITY_OPT	Comma-separated --security-opt values (e.g. systempaths=unconfined).
YASP_LAUNCH_DOCKER_PRIVILEGED	true/1/yes runs the task container privileged. Needed for hardware detection on Drive AGX.
YASP_LAUNCH_DOCKER_USER	User/UID[:GID] the task runs as (e.g. root where the compile needs it).
YASP_LAUNCH_DOCKER_SLOT_NAME	Name of the host-wide serialization slot (default yasp-launcher-slot). Two workers sharing a name take turns on the GPU.

Forwarding env into the task. The task container starts from a clean environment, so any variable it needs must be forwarded explicitly:

Variable	Effect
YASP_LAUNCH_FORWARD_ENV	Comma-separated names of env vars on the worker to copy into every task container (backend-independent).
YASP_LAUNCH_DOCKER_FORWARD_ENV	Same, Docker-host-specific, on top of the above. Typically forwards YASP_DATASET_CACHE_DIR so tasks find the mounted cache.

Tuning (rarely changed): YASP_LAUNCH_DOCKER_POLL_INTERVAL_SECONDS, YASP_LAUNCH_DOCKER_CLEANUP_TIMEOUT_SECONDS (wait for the slot to free after a task), YASP_LAUNCH_DOCKER_TIMEOUT_GRACE_SECONDS (grace added to the task timeout before the container is stopped).

Task pod settings on Kubernetes

On a Helm deployment you don't set the variables above — the chart wires the worker to create Kubernetes Jobs and renders the per-task Job template for you. The worker overwrites only the Job's name/namespace/labels and the stage container's image/command/args; everything else in the template is preserved, so the template is where all hardware targeting and isolation live.

You shape that template through the chart's job.* values — they expose nearly the whole pod spec:

Value	Effect on each task pod
job.gpu.enabled / job.gpu.resourceKey / job.gpu.count	The accelerator request (e.g. nvidia.com/gpu: 1, or amd.com/gpu for ROCm).
job.runtimeClassName	RuntimeClass that injects the GPU driver (commonly nvidia on gpu-operator clusters).
job.nodeSelector	Pin tasks to a specific GPU product (nvidia.com/gpu.product: …).
job.tolerations / job.affinity	Schedule onto tainted / specific GPU nodes.
job.resources	CPU/memory requests & limits (merged with the GPU limit).
job.volumes / job.volumeMounts	Extra mounts, e.g. a dataset-cache PVC at /mnt/dataset-cache.
job.podSecurityContext / job.securityContext	Pod- and container-level security contexts.
job.extraEnv	Extra env vars on the task container (e.g. the gpu-operator NVIDIA_VISIBLE_DEVICES=all CDI workaround).
job.labels / job.annotations	Extra labels/annotations on the task pod.
job.backoffLimit / job.ttlSecondsAfterFinished	Retry count and finished-Job cleanup TTL.
job.namespace / job.prefix	Namespace the Jobs run in (default: release namespace) and the generated Job-name prefix.

So the chart does not take a raw Job manifest to paste in wholesale, but its job.* surface lets you customize effectively the entire pod — scheduling, accelerators, volumes, security, resources, labels, and environment — which is the same control a hand-written template would give you. The only fixed parts are the bits the worker must own per task (name/namespace/labels and the stage container's image/command/args), and the stage container name itself.

YASP_LAUNCH_FORWARD_ENV also applies here: names listed on the worker are added to each task pod's container env:, overriding template entries of the same name.