Reference on TauGrid

CLI reference

Mon, 01 Jan 0001 00:00:00 +0000

The Tau CLI has exactly eight public command roots. Every example in this site uses one of these roots and its current nested subcommand path:

Root	Purpose
`tau cluster`	Install/uninstall TauGrid and validate an existing cluster
`tau workspace`	Create/adopt workspaces and inspect readiness, quota, and repo scaffolds
`tau run`	Config-first submit, lifecycle, and retry/resume for one run
`tau logs`	Find a run through configured Tau workspaces and stream its logs
`tau serve`	Render and manage serving deployments
`tau data`	Inspect dataset and model registries
`tau python`	Optionally author decorator-based `@tau.train` / `@tau.eval` workflows; standard `tau.yaml` projects do not need the Python SDK
`tau version`	Print the installed CLI version

Run evidence and the observability portal ship in a separate binary, taugrid-portal. See taugrid-portal experiment below.

Run config reference

Mon, 01 Jan 0001 00:00:00 +0000

This page documents the direct run config: the normal, hand-written tau.yaml that tau run --config reads to submit a workload. See direct run config vs. managed workflow manifest for how this differs from the SDK-generated, schema_version: 1 manifest that tau.train/tau.serve render. Both can use a tau.yaml filename; inspect the schema, not the filename. Use the managed workflow shape only when TauGrid needs to own workflow semantics such as staged train/eval lineage.

Cluster install values

Mon, 01 Jan 0001 00:00:00 +0000

This page documents the Helm values accepted by tau cluster install. The distribution chart bundles Kueue, KubeRay, the Tau core controller, GPU monitoring, the taugrid-core services chart, and a portable baseline queue into a single versioned release. Portal is enabled by default for the operator quickstart; Stellar, lifecycle recorder, and image prewarm remain disabled until the platform opts in.

Print this reference from your terminal:

TauWorkspace reference

Mon, 01 Jan 0001 00:00:00 +0000

TauWorkspace is a platform-authored Kubernetes resource in the TauGrid system namespace (tau-system by default). A custom tau cluster install --namespace <name> moves the controller and these objects together; administrative workspace commands use --system-namespace <name>, and repository descriptors persist the value as cluster.systemNamespace. It reconciles or verifies:

Target namespace and namespaced RBAC.
Kueue LocalQueue accessibility.
Workload identity ServiceAccount configuration.
Readiness and drift conditions.

Platform teams provision Azure resources and cluster-scoped quota policy, projects own their own code, and platform teams verify the durable storage PVC separately.

Release contract

Mon, 01 Jan 0001 00:00:00 +0000

TauGrid uses canonical annotated SemVer tags (vX.Y.Z) and a manually authorized GitHub Actions workflow. Publishing a release requires a manually authorized workflow run beyond the tag push itself.

The workflow:

Verifies the annotated tag and reviewed main commit.
Requires checked-in release notes.
Runs Go and Python release gates.
Compares two independent binary builds.
Builds the Python SDK wheel twice and requires byte-for-byte identical output.
Publishes raw binaries, the SDK wheel, install.sh, LICENSE, and SHA256SUMS as new assets, leaving any existing ones untouched.
Verifies every uploaded digest.
Proves CLI and SDK installation on clean Ubuntu and macOS runners.

The Python SDK keeps its own package version, but its source-aligned tau-*.whl is published in the same GitHub Release as the CLI.

Glossary

Mon, 01 Jan 0001 00:00:00 +0000

This page is the canonical source for TauGrid terminology. Other concept and reference pages link to a definition here instead of redefining it. Where a term below conflicts with older prose elsewhere, this definition wins.

TauGrid

The CLI (and its companion Python SDK) that resolves a project’s checked-in workload contract, applies platform-owned policy, renders a Kubernetes Job or KubeRay RayJob, submits it, and gives the researcher one lifecycle surface for status, logs, results, retry, and resume. TauGrid resolves, renders, and observes workload lifecycle; Kueue and Kubernetes own scheduling and orchestration, and platform teams provision cloud infrastructure. See What is TauGrid and Architecture.