zozo123 opened a new pull request, #68847: URL: https://github.com/apache/airflow/pull/68847
Follows up #68845. ## What Adds a new `Sandbox` provider (`apache-airflow-providers-sandbox`) for running Airflow tasks in ephemeral cloud sandboxes behind a pluggable backend layer (a local subprocess reference backend + Daytona, E2B, Modal, islo). Three entry points, smallest-blast-radius first: - **`SandboxOperator`** and **`@task.sandbox`** (mirrors `@task.bash`) — run one command in a sandbox from a normal task; no special executor required. - **`SandboxExecutor`** — route every task instance through a sandbox (implements the public `BaseExecutor` interface only; **no core changes**, per AIP-51). ## Why There is no executor/operator today targeting ephemeral cloud sandboxes — strong per-task isolation and a serverless execution model without standing up Celery/K8s. The motivating use case is running untrusted / LLM-generated code (agents): a fresh disposable environment per task, with model credentials injected into the sandbox only. ## Verification - `SandboxOperator` and `@task.sandbox` are verified **end-to-end** on Airflow 3.1 via `airflow dags test` on the local backend, including credential injection. - Every SaaS backend's SDK call sites are checked against the real `daytona`/`e2b`/`modal`/`islo` SDKs by `scripts/verify_sdk_conformance.py` (reference repo) — 49/49. - Unit tests for the backend contract, the executor watcher logic, the operator, and islo wiring (17 passing); ruff clean. Reference implementation, design notes and the runnable demo: https://github.com/zozo123/airflow-provider-sandbox ## Process / asks I'm aware new community providers go through `ACCEPTING_PROVIDERS.rst` (working impl + tests/docs + system-test plan + ≥2 stewards + a committer sponsor, via a dev@ `[DISCUSS]` lazy-consensus). I'm opening this to anchor the discussion against working code and am **happy to take it to the devlist and/or ship it as a third-party package** if that's preferred. Seeking steward/sponsor interest. Some breeze-generated artifacts (pyproject/get_provider_info/dependency sync) will need a regen pass by a committer. - [x] No AIP needed — implements the public `BaseExecutor` interface only, no core/API/scheduler changes (AIP-51). ##### Was generative AI tooling used to co-author this PR? - [x] Yes — **Claude (Anthropic)**. All generated code was reviewed and understood by me; tests pass locally and the SaaS SDK call sites were verified against the real SDKs. I take full responsibility for the contribution per the Gen-AI guidelines. -- 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]
