Let channel agents inspect compute usage and request bounded resizing
還沒有人認領這個 Issue。
評估
- 難度
- 5/5
- 預估耗時
- 一週以上
- 新手友好度
- 12/100
- Issue 類型
- 功能
- 描述清晰度
- 基本清楚
- 活躍度
- 活躍
- 技術堆疊
- typescript
研究方向
Start with the manual HTTP resize path in services/compute, which switches between standard-1 and standard-4 via checkpoint, destroy, start, restore and reconnect, and with the idle-only resize operation it calls. Then look at packages/channel to see where an agent-facing tool would sit without adding provider-specific logic. Done means the agent can read current size and usage, a policy-allowed request is durably queued and applied between runs, and out-of-policy or repeated requests leave compute unchanged.
由索引模型根據 Issue 內容生成。
描述
Follow-up to #216 and the services/compute pilot.
The pilot exposes manual HTTP resizing among standard-1 through standard-4. Resizing requires an idle channel and performs checkpoint → destroy → start → restore → reconnect. Agents currently have neither resource measurements nor a tool for requesting a different allocation.
Add an agent-facing capability to inspect the current allocation and request a supported size within an operator-defined policy. Keep provider-specific allocation and lifecycle operations in the compute adapter; packages/channel must remain runtime-neutral.
Acceptance:
- Report current size and measured CPU, memory, and filesystem usage, with a sampling window and unavailable metrics identified. Include evidence of resource exhaustion when the runtime supplies it; a generic command failure alone is not a sizing measurement.
- Let the operator configure allowed sizes, a maximum size, and a cooldown/attempt limit. Requests within that policy need no per-change approval. Reject unsupported or out-of-policy requests before changing compute.
- Handle the active-run boundary explicitly. For the first implementation, durably queue a request and apply it after the requesting run ends and the channel is idle; do not call the current idle-only resize operation from a busy tool and report success. Report requested, pending, applied, and failed outcomes accurately, with idempotent request handling.
- Use the existing checkpoint/restore path and process-quiescence rules. A failed checkpoint or restart must retain recoverable filesystem state and surface the failure rather than repeatedly requesting larger machines.
- Make the resulting allocation and resize outcome visible to the next run. Preserve the channel identity and lanes, and keep pi authoritative for agent work.
- Validate with a real resource-constrained workload: inspect the measurements, request an allowed larger size, restore the dirty lane, and continue the workload successfully. Also verify an out-of-policy request and a repeated request do not change compute.
This starts with measured, bounded requests and resizing between runs. Automatic cost optimization, live process migration, and a desktop sizing UI are separate work.
- 主要語言
- TypeScript
- 星號
- 1
- 分支
- 0
- PR 合併指標
- 30 天內沒有已合併 PR
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 沒有貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
githubnext/ace2 的其他 Issue
-
難度 1/5 1 小時以內 新手友好度 94/100
githubnext/ace2#487 ·
-
難度 2/5 1-3 小時 新手友好度 90/100
githubnext/ace2#486 ·
-
難度 2/5 1-3 小時 新手友好度 67/100
githubnext/ace2#459 ·
-
難度 1/5 1 小時以內 新手友好度 88/100
githubnext/ace2#437 ·
-
難度 4/5 3-5 天 新手友好度 35/100
githubnext/ace2#442 ·
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 72/100
simkimsia/netlify-axi#19 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 72/100
subhranshudash13-dotcom/Contribo#74 ·
維護者通常 1 天內回覆
-
enhancement frontend good first issue Stellar Wave trivial
難度 2/5 1-3 小時 新手友好度 76/100
Godgift-care/sci-healthcare-frontend#166 · 1 則留言 ·
維護者通常 1 天內回覆
-
backend good first issue security Stellar Wave trivial
難度 2/5 1-3 小時 新手友好度 82/100
Godgift-care/sci-healthcare-backend#171 · 1 則留言 ·
維護者通常 1 天內回覆