Repository navigation
Map the Go runner and Node sandbox integration baseline #82
Description
Outcome: the integration baseline mapping is complete. The protocol/component map (#99), reviewed source inventory (#100), telemetry and sensitive-field inventory (#101), existing capabilities and sandbox gap/ownership map (#102), acceptance app and SDK path (#103), and platform handoff (#104) are recorded. These are source and design findings; implementation and deployed acceptance remain in the delivery tickets.
AI;DR: Map the existing gateway, Node and Go runner paths, telemetry and integration gaps to guide sandbox implementation. Establish the handoff for ordinary app execution and platform-owned evaluation and observability.
Map the gateway/client → Node orchestrator → ordinary HTTP application path and the trusted adapter control path, including discovery, sessions, payment/redemption, and management boundaries. Record reviewed source revisions as evidence, without selecting a sandbox release pin ahead of implementation. The trusted adapter sends Node heartbeats directly with runner_url set to the gVisor app Service URL: Node proxies client traffic directly to the app, while the adapter handles registration and session control. See Node routing tests and #92; app images need no Livepeer SDK.
- Inventory existing logs, metrics listeners, health endpoints, identifiers, access controls, and sensitive fields. Record the Node metrics listener's bind address and exposure assumptions.
- Map existing registration, security, telemetry, and SDK compatibility capabilities (Implement runner registration, discovery, and capacity-aware sessions #25, Enforce scoped outbound grants and verified TLS #27, Expose baseline metrics, health checks, and structured runner logs #28, Exercise pinned Go and Python SDKs against a real runner process #29, Expand operational metrics and structured logs across components #52), and identify the additional k3s/gVisor integration work.
- Identify one representative app and the Python SDK discovery/call path to use for sandbox acceptance.
Acceptance: a component map, reviewed source inventory, telemetry inventory, and gap list make subsequent sandbox work actionable. Select and test compatible releases when implementing #92/#84/#86.
Platform handoff: the handoff decisions in #104 are agreed. Evaluation apps/profiles and the report contract are consolidated in #90; shared telemetry schema, correlation and result collection in #44; qualification/freshness in #91. Invocation, scheduling, storage/query APIs and dashboards belong to the observability platform. The node runs evaluation apps through its normal sandboxed app path; identify extra node work only for a demonstrated gap in generic execution.
Source: October 27, 2026 draft, Livepeer Sandbox Management and Observability Implementation Plan. Relevant sections: A; Sections 2 and 3.4.
Activity
j0sh commentedon Oct 30, 2026
The baseline mapping is complete: component/protocol boundaries, source revisions, telemetry and sensitive fields, the sandbox gap/ownership map, the acceptance app and SDK path, and the platform handoff are all recorded in the completed mapping tasks (#99–#104).
The handoff work is now consolidated into three implementation tickets: #90 for the app/verifier and profile/result contract, #44 for collection/correlation, and #91 for qualification. Runtime, isolation, payment, management and acceptance work remain open in their delivery tickets.
Closing this parent mapping ticket. The reviewed source and agreed design make implementation actionable; deployed sandbox acceptance evidence is still required in the implementation work.