Skip to content

tl deploy: build function images via sandbox-image builder (drop v2/v3)#683

Draft
diptanu wants to merge 4 commits into
mainfrom
fe-deploy-sandbox
Draft

tl deploy: build function images via sandbox-image builder (drop v2/v3)#683
diptanu wants to merge 4 commits into
mainfrom
fe-deploy-sandbox

Conversation

@diptanu
Copy link
Copy Markdown
Contributor

@diptanu diptanu commented May 15, 2026

Draft PR to trigger CI on the branch. Not ready for review yet.

Summary

`tl deploy` now builds every function image through the SDK's existing sandbox image builder (`build_sandbox_image`), registers each as a sandbox template, and ships the template name on the function manifest as `image_ref`. The legacy `v2` / `v3` Image Builder Service paths are removed entirely.

  • New: `FunctionManifest.image_ref: ImageRef | None` (kind = `sandbox_template`, id = template name).
  • Removed: `ImageBuilderV2Client`, `ImageBuilderV3Client`, `collect_application_build_request`, `ApplicationBuildRequest`, the whole `tensorlake.builder` package, `--image-builder-version` flag, `--build-env` on `tl deploy`.

Companion dataplane PR

https://github.com/tensorlakeai/compute-engine-internal/pull/919

Test plan

  • CLI tests (24) pass
  • Application-manifest tests (15) pass
  • black + isort clean
  • Rust CLI compiles

diptanu and others added 4 commits May 15, 2026 21:24
Adds `--image-builder-version sandbox` to `tl deploy`. When selected,
every unique function image is built via the SDK's existing
`build_sandbox_image()` instead of the Image Builder Service, which
registers each image as a sandbox template and gives back a template id.

A new `image_ref: ImageRef | None` field on FunctionManifest carries that
template id to the platform — kind="sandbox_template", id=template_id —
so the dataplane can resolve the function's image to a pre-built ext4
snapshot and boot a Firecracker VM from it directly, instead of importing
an OCI rootfs at runtime. When `image_ref` is absent (the v2/v3 paths,
unchanged), the platform falls through to its legacy implicit image
lookup, preserving existing behavior.

The plumbing is one parameter, `image_refs: dict[Image._id, ImageRef]`,
threaded from `cli.deploy._prepare_images_sandbox` through
`deploy_applications` → `create_application_manifest` →
`create_function_manifest`.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The dataplane resolves function images through the same internal
`/projects/{ns}/sandbox-templates/by-name/{name}` endpoint sandbox
allocations already use, so the manifest's image_ref must carry the
template name. Falls back to `image.name` if the platform response stops
echoing the template name.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The dataplane no longer resolves function images through the Image
Builder Service. The SDK's v2/v3 builder clients post to an endpoint
that's been removed downstream, so they cannot produce a working
deployment.

- Deletes ImageBuilderV2Client, ImageBuilderV3Client, log_events, the
  builder/ package shell, ApplicationBuildRequest / collect_application_build_request,
  ApplicationImageBuildError, and the tests/builder/ suite.
- Drops the --image-builder-version and --build-env flags from
  tl deploy. The Rust CLI's BuildImages command keeps its local
  --build-env (for the local Docker workflow), but the deploy help text
  no longer references it.
- tl build-images loses its --image-builder-version flag; it now only
  emits image definitions for the local Docker workflow.
- tests/cli/test_deploy.py rewritten to cover the sandbox path
  (dedupes images by Image._id, falls back to image.name when the
  platform omits it, surfaces SandboxImageBuildError as build_failed)
  plus the original helper tests.

11 deploy tests pass; 15 application-manifest tests pass; Rust CLI
compiles clean.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- .github/workflows/integration_test.yaml: drop the --build-env flags
  from the `tl deploy` step. The flag no longer exists on the Python
  argparse since the v2/v3 paths were removed; `tl build-images` keeps
  its --build-env (used by the local Docker workflow only).
- black + isort: reflow deploy.py and test_deploy.py to match the
  formatter's expected style.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant