Operator-managed execution profiles, retained workspace volumes, and approved image selection
coccyx opened ·
We would like to adopt celld's container backend for durable development workspaces, contributing generic host primitives upstream rather than maintaining separate image/lifecycle code. Docker/Podman already supply persistent mounts and stop/wait operations; the missing piece is an explicit celld integration contract.
Our tool boundary is: acquire exclusive workspace ownership, restore the accepted revision if needed, start the container with its effective policy already installed, run a tool, stop all guest processes, audit/checkpoint the retained tree externally, then publish the accepted revision and release ownership. An interactive terminal holds the same ownership until it closes. Files must remain unchanged between confirmed stop and checkpoint completion.
Proposed opt-in extension, with existing Cloudflare-compatible defaults preserved:
1. **Operator-defined execution profiles.** A deployed application selects an approved profile reference rather than supplying host paths or unrestricted daemon options. The profile sets required runtime (for example runsc), approved mounts, read-only root, CPU/RAM/PID limits, and a network policy that application/image settings cannot weaken. Selection needs a clear authorization boundary. 2. **Retained workspace mounts and stop semantics.** Associate a managed writable volume with a durable workspace identity, separately from the container's disposable root layer. Expose a stop result tied to the immutable engine container ID/run. Prevent restart/new writers until the caller completes capture or explicitly abandons or recovers the operation. Restore-before-start and capture-after-stop hooks must cover restart reaping, ownership changes, cancellation and retries. Volume retention is local; cross-node durability remains the application's checkpoint protocol. 3. **Hard deadlines and loss handling.** Enforce `hardTimeout`, or reject it if unsupported. Define how execution ends if celld freezes/crashes or loses ownership. A host watchdog integration is acceptable; a timer only inside the failed process cannot enforce that boundary. 4. **Approved image selection per workspace/agent.** Different agent definitions need different Dockerfiles/toolchains. The existing deploy-time Dockerfile build and bucket image distribution are useful and should be reused. Publish and pin a resolved image artifact before execution, rather than building each tool call. The current image-per-class configuration may need approved per-instance profile/image selection; alternatively, a documented generated-class adapter could be an initial approach. Agent-selected images must not widen the operator's execution policy. Image builds require their own controlled build context and policy.
We can keep external audit/checkpointing, filesystem quotas, network brokers and a watchdog while migrating the generic lifecycle pieces. This proposal does not ask celld to implement our application-specific checkpoint format, revision transaction or UI, or turn S3 into a live POSIX filesystem.
Useful acceptance cases:
- Detached writers cannot change the volume after stop confirmation; stop/restart and delayed old wait callbacks cannot cross run identities. - Daemon loss is reported as unknown/failure, never successful shutdown. Capture failure leaves a stopped, retained tree for retry. - Modes, symlinks, deletion and large dependency trees survive container replacement; a new node restores an application-accepted revision. - Runtime, mount, resource and network restrictions apply before any guest entrypoint, and the guest cannot select a weaker profile. - Two agent Dockerfiles resolve to distinct pinned environments; changing a definition does not silently change an already-pinned session.
The first focused lifecycle error-handling patch is available for review in our fork: https://github.com/coccyx/celld/pull/1 (eight passing regression tests; five fail against unpatched upstream). We have prepared it for the contribution instructions’ email route; it has not been emailed yet. Follow-up changes should remain small and independently testable. Feedback on the profile/mount/stop extension boundary would help keep the API useful beyond this application.