docs/todo: Add another potential redesign doc#58
Conversation
We have some work on workspace v2, but...the more I think about it the more I really do want to have a strong opinionated tie to an orchestration layer - while reusing some of the good parts of what we have here (devcontainers, service-gator) etc. Signed-off-by: Colin Walters <walters@verbum.org>
Pod startup failures in CI were undebuggable: the test harness only
reported "did not become Running within 120s" with no container logs,
exit codes, or indication of what went wrong.
Add GET /api/devaipod/pods/{name}/diagnostics that returns structured
JSON with pod state and per-container name, state, exit code, health
status, and last 50 lines of logs. Enhance the CLI `debug` command
with a Container Logs section showing the same info. Update the
integration test harness to call the diagnostics endpoint on timeout,
including container logs and last-seen pod status in failure messages.
Add test_harness_diagnostics_endpoint_captures_failure that creates a
pod with a missing agent binary and validates the diagnostics response.
Assisted-by: OpenCode (Claude Opus 4)
| 4. **Orchestration is pluggable.** For multi-agent workflows (roles, budgets, | ||
| conventions, heartbeats), the system integrates with an orchestration layer | ||
| (BotMinter/Ralph, Paperclip, or direct CLI). For simple "launch an agent | ||
| on this repo" use cases, the system works standalone. |
There was a problem hiding this comment.
I like this direction -- I was just thinking the same thing earlier today but I didn't get a chance to explore it as extensively as you have done here.
There was a problem hiding this comment.
From the investigation of paperclip, we'd just spin up synchronous podman run style wrappers that terminate, should be fine.
| │ │ │ direct CLI │ │ │ | ||
| │ │ └──────────────────────────────┘ │ │ | ||
| │ │ ┌──────────────────────────────────────────┐ │ │ | ||
| │ │ │ Agent Pod(s) │ │ │ |
There was a problem hiding this comment.
Are there other sidecars that we might want to add in the future?
There was a problem hiding this comment.
For sure, it should be configurable
| - `KubeBackend`: uses kube-rs. For Kubernetes deployments. In the k8s model, | ||
| agent pods go in an `agents` namespace with RBAC and NetworkPolicy | ||
| restricting access to the `infra` namespace where llmproxy, service-gator, | ||
| and the staging forge run. |
There was a problem hiding this comment.
Ah, so we would have a duplicated orchestration layer in k8s with namespace separation between agents in and infra. Are the options of running in a pod or k8s mutually exclusive -- those are just two different operation modes? If not, would this agent system be seen as a single virtual agent when looking at devaipod locally? Would the orchestration layers by in sync to be able to properly orchestrate all agents regardless of their location?
| decides what leaves that staging area. | ||
|
|
||
|
|
||
| ## Part 2: Architectural Components |
There was a problem hiding this comment.
For the components that need to be extracted, would you just create multiple crates within the same repo or would you be more likely create new repositories for them (i.e. within LobsterTrap)?
2 participants
We have some work on workspace v2, but...the more I think about it the more I really do want to have a strong opinionated tie to an orchestration layer - while reusing some of the good parts of what we have here (devcontainers, service-gator) etc.