[my_compute_zos_sdk] Implement typed client methods (lib.rs:24 TODO) #117

New issue

Open

opened 2026-05-22 15:20:40 +00:00 by mik-tf · 0 comments

mik-tf commented

2026-05-22 15:20:40 +00:00

Owner

Context

crates/my_compute_zos_sdk/src/lib.rs:24 ships a TODO:

// TODO: implement typed client methods for ZOS/Grid 3 compatibility operations.
// Planned domains: capacity, workload, contract, node state (translated from Grid 3).

The neighbouring crates/hero_compute_sdk/src/lib.rs exposes transport primitives (http_rpc_tcp, http_rpc_unix, URL helpers, ssh_secret_hash, HERO_PROXY_PORT, RPC path constants) but no typed method bindings for ComputeService.deploy_vm / get_vm / delete_vm / list_vms / set_ssh_keys / etc.

Why this matters

Downstream consumers calling the per-node ComputeService over cross-node JSON-RPC currently have to hand-roll the wire envelopes themselves. Specifically: at session s142, lhumina_code/hero_os_tfgrid_deployer built a ComputeAdapter in crates/hero_tfgrid_deployer_server/src/compute.rs that does exactly this — serde_json::json!() envelope construction + manual Vm decode + error wrapping. The pattern mirrors hero_compute_sdk::send_heartbeat at line 341 of that file, so it works, but every new consumer pays the same boilerplate cost.

A typed SDK would let consumers write:

let vm = sdk.deploy_vm(name, slice_count, &secret, image, &ssh_keys, &node_sid).await?;

instead of ~50 lines of envelope plumbing per method.

Suggested scope (v1)

Typed methods for the read+write methods our deployer adapter exercises:

deploy_vm(name, slice_count, secret, image, ssh_keys, node_sid) -> Vm
get_vm(sid, secret) -> Vm
delete_vm(sid, secret) -> bool
list_vms(secret) -> Vec<Vm>
set_ssh_keys(secret, keys_json) -> String
list_slices() -> Vec<Slice>
list_nodes() -> Vec<ComputeNode>

Plus a ComputeClient builder taking host: &str, port: u16 (default HERO_PROXY_PORT = 9997) and exposing both UDS + cross-node TCP transports.

Could mirror Mahmoud's existing dispatch shape from crates/my_compute_mos_server/src/cloud/rpc.rs for method-name strings (ComputeService.deploy_vm etc.).

s142 hand-rolled adapter for reference: https://forge.ourworld.tf/lhumina_code/hero_os_tfgrid_deployer/src/branch/main/crates/hero_tfgrid_deployer_server/src/compute.rs
D-23 SSH key custody (workspace decision) → drives the deployer's call shape
#116 — slice-model surface ack thread (s142 close comment)

Not blocking for the demo-deployer arc (Track D); filing for follow-up housekeeping when convenient.

— mik-tf

## Context `crates/my_compute_zos_sdk/src/lib.rs:24` ships a TODO: ``` // TODO: implement typed client methods for ZOS/Grid 3 compatibility operations. // Planned domains: capacity, workload, contract, node state (translated from Grid 3). ``` The neighbouring `crates/hero_compute_sdk/src/lib.rs` exposes transport primitives (`http_rpc_tcp`, `http_rpc_unix`, URL helpers, `ssh_secret_hash`, `HERO_PROXY_PORT`, RPC path constants) but no typed method bindings for `ComputeService.deploy_vm` / `get_vm` / `delete_vm` / `list_vms` / `set_ssh_keys` / etc. ## Why this matters Downstream consumers calling the per-node `ComputeService` over cross-node JSON-RPC currently have to hand-roll the wire envelopes themselves. Specifically: at session s142, `lhumina_code/hero_os_tfgrid_deployer` built a `ComputeAdapter` in `crates/hero_tfgrid_deployer_server/src/compute.rs` that does exactly this — `serde_json::json!()` envelope construction + manual `Vm` decode + error wrapping. The pattern mirrors `hero_compute_sdk::send_heartbeat` at line 341 of that file, so it works, but every new consumer pays the same boilerplate cost. A typed SDK would let consumers write: ```rust let vm = sdk.deploy_vm(name, slice_count, &secret, image, &ssh_keys, &node_sid).await?; ``` instead of ~50 lines of envelope plumbing per method. ## Suggested scope (v1) Typed methods for the read+write methods our deployer adapter exercises: - `deploy_vm(name, slice_count, secret, image, ssh_keys, node_sid) -> Vm` - `get_vm(sid, secret) -> Vm` - `delete_vm(sid, secret) -> bool` - `list_vms(secret) -> Vec<Vm>` - `set_ssh_keys(secret, keys_json) -> String` - `list_slices() -> Vec<Slice>` - `list_nodes() -> Vec<ComputeNode>` Plus a `ComputeClient` builder taking `host: &str, port: u16` (default `HERO_PROXY_PORT = 9997`) and exposing both UDS + cross-node TCP transports. Could mirror Mahmoud's existing dispatch shape from `crates/my_compute_mos_server/src/cloud/rpc.rs` for method-name strings (`ComputeService.deploy_vm` etc.). ## Related - s142 hand-rolled adapter for reference: https://forge.ourworld.tf/lhumina_code/hero_os_tfgrid_deployer/src/branch/main/crates/hero_tfgrid_deployer_server/src/compute.rs - D-23 SSH key custody (workspace decision) → drives the deployer's call shape - https://forge.ourworld.tf/lhumina_code/hero_compute/issues/116 — slice-model surface ack thread (s142 close comment) Not blocking for the demo-deployer arc (Track D); filing for follow-up housekeeping when convenient. — mik-tf