Converge deployer on development RPC stack #31
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "development_mik"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Normalizes deployer OpenRPC methods for the development macro stack, keeps generated params single-input, installs hero_components with the admin app set, and wires deployer secret operations to the restored context-aware hero_proc SDK.
Refs: #30
Refs: lhumina_code/hero_proc#163
Signed-by: mik-tf mik-tf@noreply.invalid
Each compute daemon (one per TFGrid network) mints VM short ids from its own sequence, so two networks can hand out the same vm_sid (for example a test VM and a main VM both numbered 005o). The vms table keyed uniqueness on vm_sid alone, so the second provision insert was rejected even though the VM already deployed on chain, leaving a running VM the deployer never recorded. Make stored VM identity composite on (daemon_label, vm_sid): - M13 recreates vms with UNIQUE(daemon_label, vm_sid) instead of UNIQUE(vm_sid). Safe on existing data (vm_sid is currently globally unique, so the composite holds for every existing row). - insert_vm writes daemon_label in the same INSERT (not a follow-up UPDATE), so the composite key is complete the instant the row exists; a separate update would let both networks' rows land under ('', vm_sid) and still collide before the label was ever set. - every vms mutator (state, webgateway, gateway_name, install_state, oauth, tenant_token, installed_releases, delete) keys on the composite, so a write can never touch the wrong network's row. - find_vm(vm_sid, optional daemon_label) resolves a VM exactly when the label is supplied, else by vm_sid alone and errors if more than one network has that id (never a silent wrong-row read or delete). - delete_vm / install_hero_stack / update_vm_services / check_build_updates gain an optional daemon_label param (openrpc + sdk) so a caller can disambiguate a shared vm_sid. Tests: same vm_sid under two daemons both insert; exact and ambiguous lookup; mutators target only the owning row. 172 server + 13 sdk green. #26 Signed-by: mik-tf <mik-tf@noreply.invalid>Mint each tester's public gateway-name-proxy on a configurable compute daemon and an ordered list of gateway-capable nodes, most-preferred first. The first node that mints a ready gateway on that daemon's network wins; a failed attempt rolls back its own on-chain workload before the next node is tried. Two new optional, secret-backed env vars (defaults empty, so an unconfigured or single-chain/QA deployment is byte-identical): TFGRID_GATEWAY_DAEMON_LABEL which daemon mints gateways (e.g. main) TFGRID_GATEWAY_NODE_SIDS ordered node ids, e.g. 8,1,13,50 (prefer gent02, fall back gent01/03/04) This lets a mainnet sandbox front testers on the mainnet gent nodes (gent02 verified converging) with automatic fallback, instead of the single hardcoded gateway node, without a rebuild to retune. Signed-by: mik-tf <mik-tf@noreply.invalid>Farm ids and node sids are not unique across TFChains (mainnet farm 1 is not QAnet farm 1), so a group's single network column forced every entry onto one network. Drop it (migration M19) and store each entry network-qualified ("net:id", e.g. "main:5"), so one group can mix nodes and farms from different networks. The Group Nodes builder drops the network select and lists your managed nodes across all networks, sectioned network then farm; ticking a farm or node records its network with it. Placement and the capacity preflight match per-entry network. This is the natural model: a group is just "these nodes, wherever they live" — an organization can run on its own nodes across networks, or be pinned to one farm it has a contract on. 206 server + 20 SDK tests; fmt and clippy clean. lhumina_code/home#291 Signed-by: mik-tf <mik-tf@noreply.invalid>The Launcher compose deploy already required an organization, but it seeded a fake default option ("Testers organization") that the client mapped to an empty vms.org tag, dropping those members into the Unassigned view; and the deploy picker scraped every org card, so the Unassigned recovery bucket was itself offered as a deploy target. Make a deployment self-consistent at the one seam that writes vms.org. When an organization name is present, handle_provision_vm now ensures a real organizations row exists for that name and the member is in its roster, before writing the tag. Without this, a name written to vms.org with no backing row would strand a member as neither a real organization (no settings, no roster) nor Unassigned (that view keys on an empty tag). A new idempotent ensure_member_in_org leaves an existing same-org roster row untouched (so the compose flow, which saves the organization first, is a no-op) and otherwise moves the member in, upholding the one-member-one-organization invariant. Client: drop the fake default organization option and the name-to-empty normalization, offer only saved organizations in the deploy picker (the Unassigned bucket and any orphaned-tag group are recovery views, never deploy targets), and prefill the "+ New organization" name with a renameable suggestion derived from the first member, so a solo deploy still gets a real, settings-capable organization from the start. lhumina_code/home#298 Signed-by: mik-tf <mik-tf@noreply.invalid>When the admin instance runs a shared OnlyOffice Document Server (hub mode with ONLYOFFICE_JWT_SECRET set) and a member's install set includes hero_office, seed that member's OnlyOffice slots so the engine can fetch and save through the member without bypassing its login gate: ONLYOFFICE_JWT_SECRET, CONNECTOR_EXTERNAL_URL (the member's own hero_proxy at mycelium:9997), OO_UPSTREAM_BASE (the admin engine at mycelium:80), and the HERO_PROXY_PUBLIC_HERO_OFFICE carve-out flag. The install path seeds the slots and restarts hero_office; the update path ("Update all instances") self-gates on hero_office being present, then seeds and re-registers hero_office plus hero_proxy with --reset so the updated binaries' new env blocks take effect. Read the shared secret from the deployer's own ONLYOFFICE_JWT_SECRET env (a new service.toml env block; adding it needs a deployer re-register). Tracked at lhumina_code/home#304 Signed-by: mik-tf <mik-tf@noreply.invalid>