lhumina_code/hero_os_tfgrid_deployer
0
0
Fork 0
Code Issues 16 Pull requests Projects Releases 3 Packages Wiki Activity Actions

Bring the deployer onto the development branch #30

New issue
Open
opened 2026-06-23 19:21:45 +00:00 by mik-tf · 3 comments
mik-tf commented 2026-06-23 19:21:45 +00:00
Owner
Copy link

Bring hero_os_tfgrid_deployer onto the development branch: point dependencies at development and rename all RPC method names to underscores (no dots) so the development code generation accepts them, across the openrpc spec, the server dispatch, the embedded JSON-RPC calls, and the SDK. Done when the deployer builds against the development branch and answers its methods over the router.

Part of lhumina_code/home_lhumina#313.

Signed-by: mik-tf mik-tf@noreply.invalid

Bring hero_os_tfgrid_deployer onto the development branch: point dependencies at development and rename all RPC method names to underscores (no dots) so the development code generation accepts them, across the openrpc spec, the server dispatch, the embedded JSON-RPC calls, and the SDK. Done when the deployer builds against the development branch and answers its methods over the router. Part of https://forge.ourworld.tf/lhumina_code/home_lhumina/issues/313. Signed-by: mik-tf <mik-tf@noreply.invalid>
mik-tf commented 2026-06-23 22:44:54 +00:00
Author
Owner
Copy link

Deployer convergence status update:

The deployer branch is based on the good integration functional state and is replaying the development-stack layer, so the integration work is not being discarded.

Local deployer progress:

  • deployer-owned OpenRPC methods were moved from dotted names to underscore names, preserving reserved rpc.discover.
  • multi-param deployer OpenRPC methods were reshaped to one inline object input so the development openrpc_client! macro accepts the spec.
  • hero_components was added to the deployer install catalog/map and auto-selected for biz/planner/kimi admin panes.
  • the tester install start loop now prefers <component>_server and falls back to bare binaries only when no server binary exists.

Focused SDK check passes for deployer. The broader server compile is blocked by hero_proc development secrets API drift: new secrets CRUD defaults every operation to core, while deployer needs context-scoped secrets for compute daemon wallets/settings and provider/tester tokens.

Blocker issue: lhumina_code/hero_proc#163

Next order: land context-aware secrets in hero_proc, then update deployer to use the new typed context-aware methods and continue this issue.

Signed-by: mik-tf mik-tf@noreply.invalid

Deployer convergence status update: The deployer branch is based on the good `integration` functional state and is replaying the development-stack layer, so the integration work is not being discarded. Local deployer progress: - deployer-owned OpenRPC methods were moved from dotted names to underscore names, preserving reserved `rpc.discover`. - multi-param deployer OpenRPC methods were reshaped to one inline object input so the development `openrpc_client!` macro accepts the spec. - `hero_components` was added to the deployer install catalog/map and auto-selected for biz/planner/kimi admin panes. - the tester install start loop now prefers `<component>_server` and falls back to bare binaries only when no server binary exists. Focused SDK check passes for deployer. The broader server compile is blocked by `hero_proc` development secrets API drift: new secrets CRUD defaults every operation to `core`, while deployer needs context-scoped secrets for compute daemon wallets/settings and provider/tester tokens. Blocker issue: https://forge.ourworld.tf/lhumina_code/hero_proc/issues/163 Next order: land context-aware secrets in hero_proc, then update deployer to use the new typed context-aware methods and continue this issue. Signed-by: mik-tf <mik-tf@noreply.invalid>
mik-tf commented 2026-06-23 23:13:37 +00:00
Author
Owner
Copy link

Progress update:

  • Confirmed the deployer branch still preserves integration work: origin/integration is an ancestor of development_mik.
  • Updated deployer server code to consume the restored hero_proc multi-domain context secret API and current jobs().service_restart input shape.
  • Existing deployer convergence work remains in place: underscore OpenRPC methods, one-input params, hero_components inclusion for biz/planner/kimi admin apps, and setup-binaries server binary fallback.
  • Checks passed with a non-persistent Cargo local patch to the hero_proc#163 branch: cargo +1.96 test -p hero_tfgrid_deployer_server component_admin_apps_pull_in_hero_components and cargo +1.96 check -p hero_tfgrid_deployer_server. Also passed cargo +1.96 check -p hero_tfgrid_deployer_sdk, bash -n setup-binaries.sh, git diff --check, and OpenRPC invariants: 0 non-reserved dotted methods and 0 multi-param methods.

Normal deployer checks remain sequenced behind hero_proc#163 landing on development, because the current Forge development hero_proc_sdk does not yet expose ContextSecret* or *_context methods.

Signed-by: mik-tf mik-tf@noreply.invalid

Progress update: - Confirmed the deployer branch still preserves integration work: origin/integration is an ancestor of development_mik. - Updated deployer server code to consume the restored hero_proc multi-domain context secret API and current jobs().service_restart input shape. - Existing deployer convergence work remains in place: underscore OpenRPC methods, one-input params, hero_components inclusion for biz/planner/kimi admin apps, and setup-binaries server binary fallback. - Checks passed with a non-persistent Cargo local patch to the hero_proc#163 branch: cargo +1.96 test -p hero_tfgrid_deployer_server component_admin_apps_pull_in_hero_components and cargo +1.96 check -p hero_tfgrid_deployer_server. Also passed cargo +1.96 check -p hero_tfgrid_deployer_sdk, bash -n setup-binaries.sh, git diff --check, and OpenRPC invariants: 0 non-reserved dotted methods and 0 multi-param methods. Normal deployer checks remain sequenced behind hero_proc#163 landing on development, because the current Forge development hero_proc_sdk does not yet expose ContextSecret* or *_context methods. Signed-by: mik-tf <mik-tf@noreply.invalid>
mik-tf commented 2026-06-24 06:32:44 +00:00
Author
Owner
Copy link

Mainnet Hero Explorers bootstrap status:

  • hero_proc#163 is merged and local hero_proc was upgraded to the multi-domain/context-aware secrets API.
  • Deployer convergence landed on development through PRs #31/#32/#33/#34/#35. Current deployer development head is 1218f91.
  • Local admin deployer is running the final hardened server and can reach mainnet compute via 127.0.0.1:9988; compute wallet context is core, network main, twin id 14199.
  • Node 7084 was checked live and is dedicated/rentable but currently down/unhealthy, so I used shared mainnet node 8 (gent02.grid.tf) after explicitly enabling the shared-node gates. Node 8 is registered as main:006c.
  • Hero Explorers stack/settings/node group/org are saved. Forge users heroexplorer01, heroexplorer02, heroexplorer03 were created.
  • Member VMs are provisioned and ready on node 8:
  • Deployer reports all three members state=running, install_state=ready, release_channel=latest-development.
  • Local member health checks pass for cockpit through router. Public gateway health path returns 302 to auth, expected.

Remaining: final deployer CI run 30022 is still running for 1218f91; latest-development will move from prior good fc0a7a3 after that succeeds. Also follow up on hero_db_server not being in the installed release set and hero_kimi_web failing while hero_kimi_server is running.

Signed-by: mik-tf mik-tf@noreply.invalid

Mainnet Hero Explorers bootstrap status: - `hero_proc#163` is merged and local hero_proc was upgraded to the multi-domain/context-aware secrets API. - Deployer convergence landed on `development` through PRs #31/#32/#33/#34/#35. Current deployer `development` head is `1218f91`. - Local admin deployer is running the final hardened server and can reach mainnet compute via `127.0.0.1:9988`; compute wallet context is `core`, network `main`, twin id `14199`. - Node 7084 was checked live and is dedicated/rentable but currently down/unhealthy, so I used shared mainnet node 8 (`gent02.grid.tf`) after explicitly enabling the shared-node gates. Node 8 is registered as `main:006c`. - Hero Explorers stack/settings/node group/org are saved. Forge users `heroexplorer01`, `heroexplorer02`, `heroexplorer03` were created. - Member VMs are provisioned and ready on node 8: - `heroexplorer01` VM `006p`: https://heroexplorer01.gent02.grid.tf - `heroexplorer02` VM `006r`: https://heroexplorer02.gent02.grid.tf - `heroexplorer03` VM `006t`: https://heroexplorer03.gent02.grid.tf - Deployer reports all three members `state=running`, `install_state=ready`, `release_channel=latest-development`. - Local member health checks pass for cockpit through router. Public gateway health path returns 302 to auth, expected. Remaining: final deployer CI run 30022 is still running for `1218f91`; `latest-development` will move from prior good `fc0a7a3` after that succeeds. Also follow up on `hero_db_server` not being in the installed release set and `hero_kimi_web` failing while `hero_kimi_server` is running. Signed-by: mik-tf <mik-tf@noreply.invalid>
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
development
development_mik_deployer_installer_direct_starts
development_mik_deployer_setup_lab_service
development_mik_deployer_compute_env
development_mik_admin_proc_status
development_mik
development_sameh_drop_override_env
integration
main
development_mik_home278
latest-development
latest-integration
latest-main
latest
dev
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lhumina_code/hero_os_tfgrid_deployer#30
No description provided.