You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adding a CRUD API for workers seems like the right foundation for #729. Having a first-class worker resource API will make worker lifecycle management explicit instead of relying on implicit synchronization paths.
A few things worth considering as part of the design:
Define the worker resource model clearly (identity, status, capabilities, runtime/sandbox class, pool membership, health, and lifecycle state).
Keep create/update/delete semantics aligned with the eventual controller reconciliation model so API operations represent desired state rather than directly mutating runtime state.
Include status reporting separately from spec fields to avoid mixing user intent with observed worker conditions.
Consider idempotency and concurrency handling, since worker state may also be updated by the WorkerPoolSyncer/controller.
This should provide a clean API boundary for #729 and make future worker orchestration features easier to build.
Activity
troychiu commentedon Aug 5, 2026
Hi Scott Funkenhauser (@sfunkenhauser) I can help with this one
sfunkenhauser commentedon Aug 5, 2026
I've already started working on this, so let me keep it.
troychiu commentedon Aug 5, 2026
Sounds good. Thanks for letting me know. I can help with #729, if you'd like.
AiWatson343 commentedon Aug 6, 2026
Adding a CRUD API for workers seems like the right foundation for #729. Having a first-class worker resource API will make worker lifecycle management explicit instead of relying on implicit synchronization paths.
A few things worth considering as part of the design:
Define the worker resource model clearly (identity, status, capabilities, runtime/sandbox class, pool membership, health, and lifecycle state).
Keep create/update/delete semantics aligned with the eventual controller reconciliation model so API operations represent desired state rather than directly mutating runtime state.
Include status reporting separately from spec fields to avoid mixing user intent with observed worker conditions.
Consider idempotency and concurrency handling, since worker state may also be updated by the WorkerPoolSyncer/controller.
This should provide a clean API boundary for #729 and make future worker orchestration features easier to build.
Introduce the worker API (#1000)
Implementation for the worker API (#1121)