shivaam commented on issue #61645:
URL: https://github.com/apache/airflow/issues/61645#issuecomment-4211310375
Hi, I'd like to work on this. I'm thinking of a phased approach:
**Phase 1** (ready to submit): Read-only API + refresh trigger
- `GET /api/v2/dagBundles` — list all bundles (paginated, sortable)
- `GET /api/v2/dagBundles/{name}` — get single bundle details
- `PATCH /api/v2/dagBundles/{name}` — enable/disable
- `PUT /api/v2/dagBundles/{name}/refresh` — trigger bundle refresh (async,
fire-and-forget). This inserts a `DagPriorityParsingRequest` and the DAG
Processor picks it up on its next loop iteration — same pattern as the existing
`parseDagFile` endpoint. Synchronous refresh would require architectural
changes to the DAG Processing Manager.
- Unit tests (20 tests covering success, 401, 403, 404, pagination, sorting)
- Basic UI list page under Admin nav
No DB migration needed — this exposes the existing `dag_bundle` table
through a proper API surface.
**Phase 2** (pending design feedback): Full CRUD
- DB migration to add `classpath`, `kwargs`, `source` columns to `dag_bundle`
- `POST /dagBundles` and `DELETE /dagBundles/{name}` endpoints
- Classpath allowlisting for security (only approved bundle types via API)
- DAG Processor polling for DB-created bundle changes
Phase 2 has security implications (classpath storage = code execution) and
would benefit from maintainer input on the design. Happy to start a dev mailing
list thread if needed.
Would Phase 1 be welcome as an initial PR?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
