Specification#
Workflow#
Field Name |
Type |
Required |
Description |
|---|---|---|---|
name |
|
Yes |
The name of the workflow. |
pool |
|
No |
The pool to submit the workflow to. |
labels |
|
No |
Immutable workflow metadata copied to every task pod. See Workflow Labels. |
timeout |
|
No |
|
resources |
|
No |
Dictionary of resource specifications |
tasks |
|
Yes (or groups) |
List of task definitions. |
groups |
|
Yes (or tasks) |
List of group definitions. |
Workflow Labels#
Labels are immutable metadata for a workflow, set at submission. Keys and
values use Kubernetes label syntax, values must be non-empty, and a workflow
can define at most 16 labels. Labels are stored with the submitted
specification and copied to task pods only. Any syntactically valid key is
accepted; if a key collides with a system-owned pod label (an osmo.
selector or a scheduler queue label), the system value wins on the pod.
workflow:
name: training
labels:
team: robotics
experiment: run42
tasks:
- name: train
image: ubuntu:24.04
command: [bash]
args: [-lc, "echo training"]
Your administrator may require particular keys. In warn mode a submission
succeeds but prints a warning, so a requirement can be announced before it is
enforced; in enforce mode it is rejected. Use Workflow Submission to
validate labels, or to override them without editing a shared specification.
Your administrator may also configure a prefix added to label keys on task
pods, so a pod can show example.com/team where the specification said
team.
Task#
Field Name |
Type |
Required |
Description |
|---|---|---|---|
name |
|
Yes |
The name of the task (unique within the workflow). |
image |
|
Yes |
The container image registry and image tag, ex: |
lead |
|
No |
The group leader designation of the task. Only applicable if the task is part of a Group. |
command |
|
Yes |
The command to run in the container. |
args |
|
No |
The arguments to pass to the command. |
environment |
|
No |
The environment variables to set in the container. |
credentials |
|
No |
The credentials to inject into the container. See Secrets for more information. |
inputs |
|
No |
The inputs to download into the task container. See Inputs for more information. |
outputs |
|
No |
The outputs to upload after completion. See Outputs for more information. |
files |
|
No |
The files to mount into the task container. See File Injection for more information. |
resource |
|
No |
Reference to the |
volumeMounts |
|
No |
The volumes to mount into the task container. See Host Mounts for more information. |
exitActions |
|
No |
The exit actions to perform after the task terminates. See Exit Actions for more information. |
checkpoint |
|
No |
The checkpoint specifications to use for this task. See Checkpointing for more information. |
privileged |
|
No |
The privileged mode setting that grants containers nearly unrestricted access to the host system. Note Please consult your administrator to enable this feature. |
hostNetwork |
|
No |
The task pod host network setting that allows a pod to use the host node’s network namespace instead of having its own isolated network stack. Note Please consult your administrator to enable this feature. |
Group#
Field Name |
Type |
Required |
Description |
|---|---|---|---|
name |
|
Yes |
The name of the group (unique within the workflow). |
barrier |
|
No |
Default is See Barriers for more information. |
ignoreNonleadStatus |
|
No |
Default is When set to Note When a task gets rescheduled, the other tasks in the group continue running. If you want the other tasks to be restarted, please set |
tasks |
|
Yes |
The list of tasks in the group. See Task for more information. Important Each group must have 1 lead task. |
See also
Already have a workflow spec and ready to submit? See Workflow Submission for more information.