Deployment Manifest Generation and Serialization

Deployment: Manifest Generation and Serialization

This page covers the first two stages of the Theia pipeline: the manifest Python layer (the .art model loaded into an in-memory object graph) and its serialization to JSON (the four AUTOSAR deployment manifests). The Bazel build and provisioning stages have their own treatment; the conceptual AUTOSAR mapping is in Manifest-Structure-and-ARA-Requirements.

All artheia commands assume the workspace venv is on PATH (PATH="$PWD/.venv/bin:$PATH").

The pipeline, end to end

 .art (system/, services/)
   │  load_platform_services(system/services)
   ▼
 manifest python layer ── services/manifest/service.py (FC catalog layer)
   │                       apps/manifest/rig.py        (the demo Rig)
   │  executor emit / gui emit / generate-manifest
   ▼
 serialized JSON ── executor.json, machines.yaml, dist/manifest/<machine>/*.json
   │  rig_ext (//rules:rig.bzl)  /  theia manifest + theia install
   ▼
 bazel build @rig_apps//… ── bundles; install/ runtime layout
   │  puppet / deploy_rpi4.sh
   ▼
 provisioned / installed machines

1. The manifest Python layer

The .art model is loaded into a Python object graph called a Rig — the complete deployment: machines, applications, the FC service manifest, the process / execution tree, and the supervisor hierarchy.

• FC catalog — artheia/artheia/manifest/clusters.py lists the 18 FCs (CLUSTERS / BY_SHORT). loader.py:load_platform_services(art_root) walks <art_root>/<short>/package.art for each FC, reading the atomic node's TIPC binding into a LoadedFc. art_root defaults to system/services (platform.py:_default_art_root / PLATFORM_SERVICES_ROOT) — the aggregation symlink tree.
• PlatformBase (artheia/artheia/manifest/platform.py) — the base Rig: one application holding all FC components, the service manifest derived from the .art TIPC addresses, the per-FC processes, and the supervisor tree.
• services/manifest/service.py — the FC-layer plus the hand-authored supervisor tree (ar_sup / core_sup / network_sup / host_svc_sup / pltf_sup / app_sup), with shwa pinned to the compute machine.
• apps/manifest/rig.py (and zonal_rig.py) — the demo vehicle (apps): composes the layers, then splits onto two target machines (central runs the platform services minus shwa plus the apps; compute runs shwa plus p3). In a consuming workspace this is the user's own apps/manifest/rig.py scaffolded by theia init; the FC catalog layer above is symlinked from $THEIA_ROOT.

2. Serialization to JSON

Three commands serialize a Rig. The TARGET is a Python import path (e.g. apps.manifest.rig), not module:attr; pick the Rig attribute with --rig (defaults to *Rig / Rig).

command	emits
artheia executor emit <module> [--machine M] [--out f]	executor.json — the supervisor tree (whole-rig, or sliced to one machine)
artheia gui emit <module> [--out f]	machines.yaml — per-machine gRPC endpoints for the GUI
artheia generate-manifest <module> [--out dist/manifest]	per-machine {machine,application,service,execution}.json + index.json

artheia executor emit apps.manifest.rig                       # whole-rig tree → stdout
artheia executor emit apps.manifest.rig --machine compute_host --out central.json
artheia gui emit apps.manifest.rig --out machines.yaml
artheia generate-manifest apps.manifest.rig --out dist/manifest

The four per-machine manifests (the AUTOSAR deployment-manifest set; see Manifest-Structure-and-ARA-Requirements):

File	Describes
machine.json	hardware arch, OS packages
application.json	software components on this machine
service.json	FC instances pinned here (SOA bindings)
execution.json	processes, process→machine map, supervisor slice, node→cpu mappings

These three commands are exactly what rules/rig.bzl shells out to under the hood (via artheia rig-deps) — but you can run them by hand to inspect a rig without touching Bazel.

The theia wrappers

In day-to-day use you drive the pipeline through the theia launcher rather than the raw artheia verbs:

artheia gen-manifest apps/system/apps/component.art apps/manifest/app.py  # .art → Python manifest module
theia manifest        # the rig → dist/manifest/*.json
theia install         # stage the runtime layout (deb-mode stages /opt/theia/bin binaries)
theia start           # supervisor forks the FC daemons

The broader command surface

artheia --help lists everything. The load-bearing system-regen commands above plus the ones you will meet:

command	purpose
parse	full-tree resolve (validation) — artheia parse system/system.art
gen-netgraph	nodes + compositions → JSON netgraph (symbolic port → TIPC LUT)
gen-proto	.proto emission from .art (one file per message)
gen-manifest	system .art → the FC manifest Python module (services/manifest/service.py)
gen-app	the C++ app scaffold (lib + main + impl) — the single C++-from-.art path
gen-rig	bootstrap a vendor rig.py from a top-level .art
audit-manifest	.art ↔ rig.py drift check
rig-deps	the JSON the Bazel rig extension consumes
gen-etcd	etcd seed for the per-node config <Msg> store (the dynamic config, NOT static params)