Provision a hero_compute_mos_server endpoint we can hit for the deployer's first live smoke #118

New issue

Open

opened 2026-05-23 02:42:27 +00:00 by mik-tf · 1 comment

mik-tf commented

2026-05-23 02:42:27 +00:00

Owner

Hey @mahmoud, before wiring hero_os_tfgrid_deployer into a real provisioning flow we want to do a single end-to-end deploy_vm + get_vm + delete_vm round-trip against a live hero_compute_mos_server, and we don't currently have one reachable from our workstation. Could you either point us at a mainnet node with the host:port + node_sid to use, or tell us what we'd need to do to stand one up ourselves? Cross-link to #116 for the API surface.

Hey @mahmoud, before wiring `hero_os_tfgrid_deployer` into a real provisioning flow we want to do a single end-to-end `deploy_vm` + `get_vm` + `delete_vm` round-trip against a live `hero_compute_mos_server`, and we don't currently have one reachable from our workstation. Could you either point us at a mainnet node with the `host:port` + `node_sid` to use, or tell us what we'd need to do to stand one up ourselves? Cross-link to #116 for the API surface.

mik-tf referenced this issue

2026-05-23 03:25:02 +00:00

hero_os_tfgrid_deployer integration: methods we'll consume + small gaps #116

mik-tf referenced this issue from lhumina_code/home

2026-05-23 03:39:32 +00:00

[META] Hero OS demo-deployer arc tracker (cockpit + proxy + content + deployer + manifest + integration) #235

mik-tf commented

2026-05-23 13:17:10 +00:00

Author

Owner

Demoting this from blocker to future second adapter, no longer gating the demo arc.

Update from 2026-05-23: we self-hosted hero_compute_zos locally against TFChain mainnet using an existing operator wallet. The daemon is supervised under hero_proc, listens on a Unix domain socket, and a live ComputeService.node_register round-trip against mainnet Grid Proxy returned a ComputeNode for the chosen node. Architecture lock is captured in a workspace decision file. The deployer still has two small code edits to land before it can route requests at the self-hosted instance (a hardcoded service-name path constant in compute.rs and an HERO_COMPUTE_NODE_ADDR value), and we still need to confirm twin-ownership of the target node before any deploy_vm write hits the chain. Both items will be handled in the next session.

The Mahmoud-operated endpoint remains useful as a possible second adapter if multi-source compute is ever desired; we just no longer need it on the critical path. Closing the operational dependency framing here. Happy to reopen if a specific multi-source use case surfaces.

Signed-by: mik-tf

Demoting this from blocker to future second adapter, no longer gating the demo arc. Update from 2026-05-23: we self-hosted `hero_compute_zos` locally against TFChain mainnet using an existing operator wallet. The daemon is supervised under hero_proc, listens on a Unix domain socket, and a live `ComputeService.node_register` round-trip against mainnet Grid Proxy returned a `ComputeNode` for the chosen node. Architecture lock is captured in a workspace decision file. The deployer still has two small code edits to land before it can route requests at the self-hosted instance (a hardcoded service-name path constant in `compute.rs` and an `HERO_COMPUTE_NODE_ADDR` value), and we still need to confirm twin-ownership of the target node before any `deploy_vm` write hits the chain. Both items will be handled in the next session. The Mahmoud-operated endpoint remains useful as a possible second adapter if multi-source compute is ever desired; we just no longer need it on the critical path. Closing the operational dependency framing here. Happy to reopen if a specific multi-source use case surfaces. Signed-by: mik-tf