On many occasions, I’ve observed that integrating a new external lab into KernelCI is challenging, especially when the lab cannot (or should not) expose direct submission access to Maestro due to security/IT constraints.
Problem
Today the documentation is spread across multiple pages and assumes familiarity with Maestro’s Pub/Sub events, pipeline configuration, runtime tokens/callbacks, and scheduler. This makes it difficult for new labs to quickly stand up a local environment that:
- consumes Maestro events (subscriber),
- triggers KernelCI pipeline jobs (scheduler),
- executes those jobs in a lab runtime (e.g. LAVA),
- and reports results back via callback / results publishing path.
Proposal
Create a single, step-by-step document for external kernelci-lab which can guide lab owners through the minimum working setup:
- Conceptual flow (Maestro events → pipeline services → runtime execution → callback/results), with a small diagram.
- Minimal config snippets showing what must be added to:
- pipeline runtimes (e.g., Pull Labs runtime),
- scheduler entries targeting that runtime,
- secrets/tokens for callbacks.
- A local demo path using the existing example tooling (where applicable) so a lab can validate the integration before plugging real hardware.
- A short troubleshooting section for common onboarding issues (tokens, callback auth, event visibility, etc.).
On many occasions, I’ve observed that integrating a new external lab into KernelCI is challenging, especially when the lab cannot (or should not) expose direct submission access to Maestro due to security/IT constraints.
Problem
Today the documentation is spread across multiple pages and assumes familiarity with Maestro’s Pub/Sub events, pipeline configuration, runtime tokens/callbacks, and scheduler. This makes it difficult for new labs to quickly stand up a local environment that:
Proposal
Create a single, step-by-step document for external kernelci-lab which can guide lab owners through the minimum working setup: