hip(0004): multi-sandbox remote orchestration proposal - #1843
siennathesane wants to merge 1 commit into
Conversation
Signed-off-by: Sienna Meridian Satterwhite <sienna@sunbeam.pt>
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
The proposal doc has a few correctness/clarity and template-compliance issues (typo, platform-specific lifecycle wording, and line-wrapping) that should be fixed before merge.
Get a fresh assessment by requesting another Copilot review.
Review effort: Lite
Findings: 1
Open (1)
What changed in this PR
Adds HIP 0004 as a new design proposal describing an experimental hyperlight-remote crate that enables true parallel multi-sandbox execution by hosting each sandbox inside a surrogate helper process and exposing a SandboxBuilder/MultiUseSandbox-shaped API to the host.
Changes:
- Introduces a full HIP document covering goals/non-goals, design, protocol, lifecycle, and risks/mitigations.
- Defines an initial API sketch and IPC protocol shape for high-level operation remoting.
- Includes a concrete test plan (unit/integration/e2e) and implementation history tying the proposal to prior PRs/issues.
| File | Description |
|---|---|
| proposals/0004-multi-sandbox-remote-orchestration/README.md | New HIP proposal document for remote surrogate-process orchestration to enable parallel sandboxes (esp. on macOS/HVF). |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
|
||
| #### Story 1 | ||
|
|
||
| A developer at a startup building a parallel function-execution framework uses an Apple silicon MacBook as their primary machine. Their scheduler tests launch dozens of sandboxes with varying execution times and assert on contention, overlap, and preemption behaviour. Today they must either run these tests on remote Linux machines or accept the one-at-a-time execution of the #1674 backend, which makes the tests meaningless. With `hyperlight-remote`, the same tests run locally: each sandbox lives in its own surrogate process, guests execute in parallel, and the wall-clock assertions behave the same as they do on a Linux CI runner. |
|
@simongdavies @syntactically can you take a look since you've both prototyped and been involved here?
That would be great. Will review it for then so we can focus on the open questions |
Hey hey. Sorry it took so long. My startup got infrastructure funding and we've been moving our infrastructure to new baremetal hosts and just ugh lol. So much work.
I'm okay if this doesn't make it into v0.18 purely because it took me awhile to come back to it. I think the impl of it would be straightforward & relatively quick, so there's still room if you want it. Is there a release cut-off date for v0.18 before Oct 5?
This is my first pass based on synthesizing everything we discussed and all the feedback, as well as changes since I was last present. I should be able to make the next community meeting to discuss if needed. Please poke holes in this because I would like to get it as right since it's developer ergonomics. I did specify this was a non-production implementation, and that should help take some stress off the design & impl.
Rendered.