Marketplace integration: need dev explorer endpoint for testing #48

New issue

Closed

opened 2026-03-28 06:35:21 +00:00 by mik-tf · 2 comments

mik-tf commented

2026-03-28 06:35:21 +00:00

Owner

Context

The Mycelium Marketplace (mycelium_code/home#51) has integrated hero_compute via a lightweight TCP JSON-RPC client. The code calls the explorer for:

ExplorerService.node_list / node_get / node_search
ExplorerService.deploy_vm / start_vm / stop_vm / delete_vm
ExplorerService.list_slices / list_vms / get_vm

Request

We need a hero_compute_explorer instance running with --tcp_port so the marketplace backend can connect remotely.

On this machine, hero_compute_server and hero_compute_ui are running (root PIDs) but the explorer is not started. Would it be possible to:

Start hero_compute_explorer --tcp_port 9003 (or any port) in master mode
Register the existing compute server as a worker node
Share the TCP address so we can point HERO_COMPUTE_EXPLORER_ADDRESS at it

Or if there's already an explorer running somewhere, let us know the address.

Our integration code

src/services/impl_compute/compute_client.rs — TCP JSON-RPC client (20 typed methods)
src/services/impl_compute/slice_rental_manager.rs — deploys real VMs on slice rental
Activated via APP_COMPUTE_BACKEND=compute + HERO_COMPUTE_EXPLORER_ADDRESS=host:port

— mik-tf

## Context The Mycelium Marketplace (https://forge.ourworld.tf/mycelium_code/home/issues/51) has integrated hero_compute via a lightweight TCP JSON-RPC client. The code calls the explorer for: - `ExplorerService.node_list` / `node_get` / `node_search` - `ExplorerService.deploy_vm` / `start_vm` / `stop_vm` / `delete_vm` - `ExplorerService.list_slices` / `list_vms` / `get_vm` ## Request We need a hero_compute_explorer instance running with `--tcp_port` so the marketplace backend can connect remotely. On this machine, `hero_compute_server` and `hero_compute_ui` are running (root PIDs) but the explorer is not started. Would it be possible to: 1. Start `hero_compute_explorer --tcp_port 9003` (or any port) in master mode 2. Register the existing compute server as a worker node 3. Share the TCP address so we can point `HERO_COMPUTE_EXPLORER_ADDRESS` at it Or if there's already an explorer running somewhere, let us know the address. ## Our integration code - `src/services/impl_compute/compute_client.rs` — TCP JSON-RPC client (20 typed methods) - `src/services/impl_compute/slice_rental_manager.rs` — deploys real VMs on slice rental - Activated via `APP_COMPUTE_BACKEND=compute` + `HERO_COMPUTE_EXPLORER_ADDRESS=host:port` — mik-tf

mik-tf referenced this issue from coopcloud_code/home

2026-03-28 12:21:50 +00:00

Marketplace v2.0 — Master Tracker #40

mik-tf commented

2026-04-02 03:28:33 +00:00

Author

Owner

Resolved — deployed hero_compute on marketplace dev VM

We installed and configured hero_compute directly on the dev VM (TFGrid, KVM available):

hero_compute_server    running (pid 902767)
hero_compute_explorer  TCP port 9002
hero_compute_ui        port 9001
my_hypervisor v0.1.4   all checks passed
cloud-hypervisor v43.0

Node registered: devpmmarketplace — 1 slice (4GB RAM, 100GB disk), status online.

Marketplace backend now connects to 172.17.0.1:9002 (Docker host gateway → explorer TCP). Startup log:

Using OSIS + hero_ledger + hero_compute (172.17.0.1:9002)

No external explorer needed — we run everything on the same VM.

Note: had to use my_hypervisor v0.1.4 (v0.1.2 had old binary name chvm). The configure.sh script defaults to v0.1.2 — may want to bump to v0.1.4.

— mik-tf

## Resolved — deployed hero_compute on marketplace dev VM We installed and configured hero_compute directly on the dev VM (TFGrid, KVM available): ``` hero_compute_server running (pid 902767) hero_compute_explorer TCP port 9002 hero_compute_ui port 9001 my_hypervisor v0.1.4 all checks passed cloud-hypervisor v43.0 ``` Node registered: `devpmmarketplace` — 1 slice (4GB RAM, 100GB disk), status online. Marketplace backend now connects to `172.17.0.1:9002` (Docker host gateway → explorer TCP). Startup log: ``` Using OSIS + hero_ledger + hero_compute (172.17.0.1:9002) ``` No external explorer needed — we run everything on the same VM. **Note**: had to use my_hypervisor v0.1.4 (v0.1.2 had old binary name `chvm`). The configure.sh script defaults to v0.1.2 — may want to bump to v0.1.4. — mik-tf

mik-tf commented

2026-04-02 03:35:44 +00:00

Author

Owner

Update: VM deployment tested end-to-end

We deployed a VM through the explorer and it worked through the full pipeline:

State: provisioning → error
Logs:
  Starting deployment...
  Target node: devpmmarketplace
  Allocating 1 slice(s)...
  Slice size: 100 GB disk, 4096 MB RAM
  Allocated slices: ["0002"]
  Pulling VM image: ubuntu-24.04
  Provisioning via hero_proc job 10
  ERROR: exited with code 1
    > Error: OCI error: Not authorized: url https://index.docker.io/v2/library/ubuntu-24.04/manifests/latest

The pipeline works (slice allocation, provisioning job, logging, error handling). The failure is an image resolution issue — ubuntu-24.04 resolves to Docker Hub instead of the hero_compute registry at forge.ourworld.tf/lhumina_code/hero_compute_registry/ubuntu-24.04:latest.

Minor bugs found during setup

configure.sh defaults to my_hypervisor v0.1.2 — that release has old binary names (chvm instead of my_hypervisor). Download fails. Fix: bump default to v0.1.4
Image name resolution — deploy_vm with image: "ubuntu-24.04" tries Docker Hub. The list_images() response shows the full reference (forge.ourworld.tf/...) but the deploy doesn't prefix it. Either:
- The client should pass the full registry reference, or
- The server should auto-resolve short names against the configured registry
Explorer heartbeat in master mode — when running --start --mode master, the local server doesn't auto-send heartbeats to the co-located explorer. We had to send them manually. In local/single-node mode, the explorer sees the node via Unix socket, but marks it offline after a few minutes.

None of these are blockers — the architecture works. Closing this issue since we have a working explorer.

— mik-tf

## Update: VM deployment tested end-to-end We deployed a VM through the explorer and it worked through the full pipeline: ``` State: provisioning → error Logs: Starting deployment... Target node: devpmmarketplace Allocating 1 slice(s)... Slice size: 100 GB disk, 4096 MB RAM Allocated slices: ["0002"] Pulling VM image: ubuntu-24.04 Provisioning via hero_proc job 10 ERROR: exited with code 1 > Error: OCI error: Not authorized: url https://index.docker.io/v2/library/ubuntu-24.04/manifests/latest ``` The pipeline works (slice allocation, provisioning job, logging, error handling). The failure is an image resolution issue — `ubuntu-24.04` resolves to Docker Hub instead of the hero_compute registry at `forge.ourworld.tf/lhumina_code/hero_compute_registry/ubuntu-24.04:latest`. ### Minor bugs found during setup 1. **configure.sh defaults to my_hypervisor v0.1.2** — that release has old binary names (`chvm` instead of `my_hypervisor`). Download fails. Fix: bump default to v0.1.4 2. **Image name resolution** — `deploy_vm` with `image: "ubuntu-24.04"` tries Docker Hub. The `list_images()` response shows the full reference (`forge.ourworld.tf/...`) but the deploy doesn't prefix it. Either: - The client should pass the full registry reference, or - The server should auto-resolve short names against the configured registry 3. **Explorer heartbeat in master mode** — when running `--start --mode master`, the local server doesn't auto-send heartbeats to the co-located explorer. We had to send them manually. In local/single-node mode, the explorer sees the node via Unix socket, but marks it offline after a few minutes. None of these are blockers — the architecture works. Closing this issue since we have a working explorer. — mik-tf

mik-tf closed this issue

2026-04-02 03:35:44 +00:00