0.1.0

Release notes for simrun 0.1.0

The first release of simrun, a runner of simulation workflows on a small k3s cluster with Argo Workflows and Kueue, for people and agents (sbmlsim#440).

Features

• Workflows of tasks with ports. A workflow is a YAML file of tasks of task types from plugins, whose inputs read the output ports (out/<port>) of other tasks; the settings of a task are validated with the settings model of its type, so a misspelled setting is an error. The built-in type command runs a command in an image of its own.
• Split tasks on a ledger. A task type with count_units, compute_unit and merge is split into units, which the workers of its pods claim from a ledger of atomic renames in the run store. A coordinator returns once the ledger is complete and computes the units of dead workers, extra workers spread over the idle servers (fastest, at most eight pods) or the task stays on one server (single-server), and the merge runs once every unit is done; the result does not depend on the number of pods.
• Priorities, preemption and take-back. The runs of the owner of the cluster and the owner's agents, of the other people and of their agents have three priorities, each a base and a lower extra priority of Kueue, so a run of a higher priority preempts the runs of lower ones and a new run takes back the extra workers of the running runs of its own priority. A node can be reserved for one run.
• Learned resources. The memory of a pod is learned from the anonymous memory of the cgroups of earlier runs of its task type, model and cost setting; a pod killed for memory is retried once with 1.5 times the memory per process, and estimate predicts the duration of a split task from the seconds of its units.
• Snapshots and environments. The client snapshots the working trees of the model and its libraries, uncommitted changes included, into the run store with their provenance; the service locks their third party dependencies with uv, builds the image of the environment with BuildKit only when the registry does not have it, and the pods install the read-only snapshots editable at their start.
• Plans and provenance of tasks. A task type can plan its settings before a run is submitted (plan, called by the client where the type is installed, also for estimate and validate); every task gets the provenance of the sources of its run (provenance.json, SIMRUN_PROVENANCE), and a command reads its inputs through {input}, a staged input from a local copy on the scratch of the node.
• The service, the command line and the MCP server. A FastAPI service with bearer tokens of people and agents submits a run in the background and returns its id at once, follows the workflows with a stateless controller, keeps the logs of the pods and an index of the runs in SQLite beside the store; the command line simrun and the MCP server simrun-mcp of the agents submit, wait for, list, compare, cancel and clean up runs.
• Cluster deployment. deploy/cluster is the cluster as a kustomization (Kueue v0.20.5, Argo Workflows v4.1.6, the run store on NFS, Zot, BuildKit and the service), deploy/k3d the overlay of the integration tests on k3d, which verify the design on a real cluster. The same run exports as a CWL workflow for cwltool (the extra cwl).
• The web app. The service serves a web app (Vue 3, Vue Flow, Tailwind) at /ui/, live by server-sent events. Executions: the runs of people and agents with filters and groups and their progress, the capacity of the cluster, a strip of the servers with the cores and memory of every run, the canvas of a run with the state, units and workers of every task, and an inspector with the workers, outputs and live logs. Editor: simrun edit <workflow.yaml> on the machine with the code opens the workflow in the browser, which may run on another machine; a palette of the task types of the service, a canvas to add and connect tasks, the settings as a form of their JSON Schema, the resources with the estimate; Save writes the file next to the code, Run snapshots the working trees again; a file changed on disk is a conflict, not an overwrite; Rerun with changes opens a run in the Editor.
• A local test system. tests/cluster/local.py up keeps the k3d cluster of the integration tests as a local system with the service on the host, for the command line, the MCP server and the web app (examples/squares.yaml).