Extending integrations
Integrations translate external systems into framework contracts. They do not contain domain transforms.
Generic extension checklist
Section titled “Generic extension checklist”- Start from a declarative DRTML need, not a particular step id.
- Add typed/validated configuration where practical.
- Convert external values into
RunContext, namespaced params, or a neutral contract DTO. - Call existing dispatch/storage/telemetry APIs.
- Keep external SDK imports lazy and inside the integration/transport module.
- Add tests with fake clients or fake Streamlit/Airflow context.
- Document deployment/env requirements.
Add a Streamlit field
Section titled “Add a Streamlit field”- Generic scalar field: extend
_render_field. - Reusable multi-field capability: add a focused renderer module and invoke it from
DrtmlStepLauncher. - Output must be a params overlay only.
- Add UI validation and a runtime consumer.
- Never add
if step_id ==or import a step package.
Add an Airflow connection type
Section titled “Add an Airflow connection type”- Add a generic connection adapter in
integration/airflow. - Match connection ids from
orchestrator.connections. - Translate Airflow connection data into framework env/client configuration.
- Do not expose Airflow objects to processing or domain code.
- Add tests for absent, malformed, and valid connections.
Add a Ray transport capability
Section titled “Add a Ray transport capability”Connection/init remains in integration/ray. Submit/wait/object-ref logic belongs in the owning processing transport backend. Worker payloads must be picklable and contain manifest path + params rather than compiled sessions/clients.
If behavior is a computation algorithm, add it under algorithms/; if it is distributed dispatch, add a transport backend. Do not make steps import Ray.
Add Prometheus instrumentation
Section titled “Add Prometheus instrumentation”Declare the metric in DRTML, extend the emit plan/source adapter, and emit through RunMetrics. Processors may return named stats but must not call prometheus_client.
Add a Grafana panel type
Section titled “Add a Grafana panel type”- Define the DRTML view shape.
- Add a focused builder under
telemetry/dashboards. - Dispatch it from
panel_builders.py. - Keep PromQL in
promql.py, grid math inpanel_grid.py, and field config infield_config.py. - Add JSON contract tests without syncing Grafana.
Dashboard sync remains a server deployment operation.