OpenStrate Mission Architecture

This document outlines the architecture and lifecycle of distributed missions in the OpenStrate ecosystem.

Overview

OpenStrate missions are the fundamental unit of work execution. A mission consists of code (mission.py), configuration (workflow.yaml), and dependencies (artifacts). The provisioning system ensures these components are securely packaged, distributed, and executed across a decentralized network of Satellites.

Architecture Components

The mission ecosystem relies on four key components:

1. OpenStrate CLI (ostr)

The Command Line Interface is the primary entry point for users. It handles:

• Initialization: Generating boilerplate mission files.
• Packaging: Uploading code and artifacts to the Relay.
• Orchestration: Sending deployment commands to Satellites via ZMQ.
• Monitoring: Querying Constellation for job status and retrieving results.

2. OpenStrate Relay (openstrate-relay)

The central artifact repository for the local environment.

• Artifacts API: Provides HTTP endpoints (/api/artifacts) for storing and retrieving mission files.
• Namespacing: Artifacts are scoped by mission_id to prevent conflicts and ensure version consistency.

3. OpenStrate Constellation (openstrate-constellation)

The state management and discovery layer.

• Job Tracking: Maintains a centralized record of all jobs (jobs table) and satellite assignments.
• Service Discovery: Tracks active Satellites and their capabilities.
• Status Reporting: Receives updates from Satellites and serves them to the CLI.

4. OpenStrate Satellite (openstrate-satellite)

The compute node responsible for execution.

• Jail: Creates an isolated sandbox for each mission.
• Execution: Fetches artifacts from Relay, runs the mission code, and captures stdout/stderr.
• Result Handling: Scans the workspace for outputs and uploads them back to Relay.

Mission Lifecycle

The lifecycle of a mission follows a linear flow:

1. Provisioning

1. User runs ostr mission init to create mission.py and workflow.yaml.
2. User runs ostr mission push. The CLI reads the mission_id from workflow.yaml and uploads files to Relay:
   • OST_RELAY_URL/api/artifacts/missions/{mission_id}/mission.py

2. Deployment

1. User runs ostr mission deploy.
2. CLI queries Constellation for an available Satellite.
3. CLI sends a ZMQ deploy command to the target Satellite, including the mission_id and artifact URLs.
4. Satellite acknowledges and registers the job with Constellation as pending.

3. Execution

1. Satellite creates a "jail" (isolated directory).
2. Satellite downloads the mission artifacts from Relay.
3. Satellite updates job status to running.
4. Satellite executes the entry point command (e.g., python mission.py).

4. Collection

1. Upon completion, Satellite scans the workspace for generated files.
2. Satellite uploads these outputs to Relay under the job namespace:
   • OST_RELAY_URL/api/artifacts/jobs/{job_id}/results.txt
3. Satellite updates job status to completed in Constellation, listing the output artifacts.
4. Satellite cleans up the jail.

5. Retrieval

1. User runs ostr mission results <job_id>.
2. CLI queries Constellation for the list of output artifacts.
3. CLI downloads the files from Relay to the user's local machine.

Data Flow Diagram