Skip to main content

Operations

Overview​

Operations are the blueprints for executions. An operation is defined by a YAML file that specifies tasks, their order, input parameters, and outputs. Operations describe what runs, how it runs, and on which system it runs.

warning

Always consider the Engineering Model (EM) as a testing environment before deploying to the Flight Model (FM). The EM provides shorter feedback loops, while FM operations are subject to uplink and downlink windows and other constraints.

Operation example​

As an example, take the following operation test-health:

id: test-health
namespace: gamma
system: cg2.em
description: Example execution with multiple Clustergate-2 tasks.
tasks:

- id: pod_run_job
  pod_name: test
  type: dphi.space.cg2.pod.run
  description: Run a pod with parameters
  image:
    name: alpine
    tag: latest
  command:
  - /bin/sh
  args:
  - -c
  - echo 'Hello from space' > /data/hello-from-space.txt
  node: Fpga
  max_duration: 1
  volume: payload

- id: downlink_results
  type: dphi.space.cg2.downlink
  description: Downlink files to ground
  source:
  - hello-from-space.txt
  destination: /first_test
  volume: payload

This example defines an operation in which two tasks are performed sequentially on Clustergate-2's Engineering Model (cg2.em).

First, the pod_run_job task of type dphi.space.cg2.pod.run schedules a DPhi Pod to run with the parameters defined in the YAML:

  • Pod name: test.
  • Image: alpine:latest.
  • Command: /bin/sh with -c to run the inline echo command.
  • Node: FPGA.
  • Max duration: the time limit in minutes before the controller gracefully stops the pod.
  • Volume: payload mounted at /data inside the pod.

This task is expected to create hello-from-space.txt at the root of the payload volume onboard, which makes it available for the subsequent downlink step.

Then, the downlink_results task of type dphi.space.cg2.downlink will downlink this file and save it to the folder /first_test under the namespace of the operation, i.e., gamma.

For a full list of task types, see the Tasks Overview.

System​

The system field in the operation YAML specifies which DPhi system the operation should run on. It is a required field.

Currently supported values:

  • cg2.em for Clustergate-2 Engineering Model
  • cg2.fm for Clustergate-2 Flight Model

Use cg2.em for testing and validation before running on cg2.fm.

Tasks​

Tasks are the atomic units of operations. Each task represents a single action such as uplinking files, running a pod, or downlinking results. Tasks declare the inputs they need and the outputs they produce.

Some tasks emit outputs that are visible in the execution view. For example, dphi.space.cg2.downlink reports the downlinked file URIs and metadata.

The list of available tasks can be found in the Tasks section.

Revisions​

Operations are versioned. Each update creates a new revision, and the dashboard keeps the full revision history so you can review or roll back changes. In the operation detail view, the Revisions tab lets you compare differences between revisions side by side.

Deleting operations​

Deleting an operation is a soft delete. The operation revision is marked as deleted and hidden from normal views instead of being physically removed.

If you delete an operation without specifying revisions, the backend soft-deletes all revisions for that operation id in the namespace. If you target specific revisions through the API, only those revisions are soft-deleted.

Deleting an operation also soft-deletes its linked executions in the same tenant and namespace. However, the per-execution usage metric documents are not soft-deleted as part of operation deletion, so quota and usage totals continue to include those executions.

warning

An operation cannot be deleted if any linked execution is in RUNNING or SCHEDULED state.

note

Soft-deleted operation ids remain reserved. Creating a new operation with the same id in the same namespace returns a conflict instead of reusing the deleted record.

Operation lifecycle​

  1. Define the operation in YAML.
  2. Create or update the operation in the dashboard or API.
  3. Execute the operation with optional scheduling.
  4. Inspect task runs, logs, and outputs.
  5. Iterate on the YAML and update the operation as needed.