Joseph Doherty
6c81c0bc0a
LeaderResolver searched every instance of the application, so co-located groups (QA: ScadaBridge central-a and site-a both on vq03) got the first-listed group's instance name on their leader chip. Resolution is now scoped to the group's members; an unmatched address keeps its raw form. - tests: QA co-located central/site layout; cross-group host not borrowed - CLAUDE.md: correct the leader-resolution / 127.0.0.1 guidance - code-reviews: Overview-002 Resolved; README regenerated Claude-Session: https://claude.ai/code/session_01GT67AEHd2Acv1YPwGfXEoV
68 lines
4.8 KiB
Markdown
68 lines
4.8 KiB
Markdown
# ZB.MOM.WW.Overview
|
|
|
|
The hosted family dashboard (Blazor Server). Build/test from this directory: `dotnet build ZB.MOM.WW.Overview.slnx`, `dotnet test ZB.MOM.WW.Overview.slnx` (fully offline).
|
|
|
|
**Backlog / open work:** lives in Gitea issues on `dohertj2/scadaproj` (`tea issues list --repo dohertj2/scadaproj`) — currently #14 (re-run the two OtOpcUa-blocked Phase 4 acceptance checks). The history below is a record, not a status tracker; file new follow-ups as issues.
|
|
|
|
## Index history (migrated from the scadaproj root CLAUDE.md)
|
|
|
|
> Moved verbatim out of the scadaproj root `CLAUDE.md` on 2026-09-03 so it loads only when needed. **This file is now the authoritative place for this history — append new entries here and keep the root index row short.**
|
|
|
|
|
|
Besides the shared libraries, this repo hosts one **application**:
|
|
[`ZB.MOM.WW.Overview/`](ZB.MOM.WW.Overview/) — a Blazor Server single-pane dashboard that polls
|
|
every registered instance's anonymous `/health/ready` + `/health/active`, caches one snapshot
|
|
(pages never poll) and renders per-cluster state including the Akka **leader chip**, which is what
|
|
the `ZB.MOM.WW.Health` `0.2.0`/`0.3.0` per-entry `data` work exists to feed. **No login, strictly
|
|
read-only, holds no credentials** — a requirement, not an omission; it references no Auth/Audit/
|
|
Secrets package. Design + impl plan: `docs/plans/2026-07-22-overview-dashboard-{design,impl-plan}.md`
|
|
(ledger 19/20; the open task is Phase 4 live acceptance, recorded in `41013dc` as 7 of 9 design §9
|
|
checks passing, 2 blocked on an OtOpcUa rig redeploy → #14).
|
|
|
|
The `Applications` registry ships **empty** on purpose: a deployment supplying none fails startup
|
|
naming the key rather than booting an empty dashboard. Per-deployment overlays are committed —
|
|
`appsettings.Docker.json` (the local rigs, joined via external networks) and
|
|
`appsettings.Wonder.json`.
|
|
|
|
**Deployed to `wonder-app-vd03` 2026-08-11** (`main @ 4f97e72`) as that box's **fifth** app:
|
|
service `ZbOverview` on **:5320** under the shared NSSM, `ASPNETCORE_ENVIRONMENT=Wonder`,
|
|
5/5 instances Up. Two constraints worth carrying to any future box:
|
|
|
|
- **Publish self-contained** (`-r win-x64 --self-contained true`). wonder has **no .NET 10 runtime**
|
|
— every app there carries its own. An FDD publish installs fine and then fails at service start.
|
|
- **Leader resolution is per group (fixed 2026-11-09, Overview-002 / scadaproj#43).** Leader-address →
|
|
instance resolution matches on **host only** (Akka and HTTP ports differ by design). It used to scan
|
|
the whole application, so co-located groups stole each other's chip — on vd03 ScadaBridge's **site**
|
|
card claimed `Leader · central`, and the same happened on QA, where central-a and site-a both run on
|
|
vq03 (the earlier note that QA "resolves as designed" was wrong). It now searches only the group's
|
|
own members and keeps the raw Akka address when none matches. The vd03 `127.0.0.1` BaseUrls are no
|
|
longer needed for correctness (each vd03 group is single-node); they remain harmless. Two members
|
|
of the **same** group on one host would still be indistinguishable by host.
|
|
|
|
**QA runs an instance on EACH pair node — `wonder-app-vq03:5320` and (since 2026-08-14)
|
|
`wonder-app-vq04:5320`** — both watching the same registry, now **10 instances across 4
|
|
applications** after the 2026-08-14 VQ04 singleton clone (MxGateway + HistorianGateway added on
|
|
vq04; see `deployment.md` §7.1). It is the fastest way to read QA's whole topology.
|
|
Its registry uses **real FQDNs**. Each QA group's two members are on distinct hosts (`vq03`/`vq04`),
|
|
which per-group resolution needs; groups sharing a host no longer matter (see above).
|
|
|
|
## Commands (from the index)
|
|
|
|
```bash
|
|
# ZB.MOM.WW.Overview (~/Desktop/scadaproj/ZB.MOM.WW.Overview — the hosted family dashboard)
|
|
dotnet build ZB.MOM.WW.Overview.slnx
|
|
dotnet test ZB.MOM.WW.Overview.slnx # 177 tests, fully offline
|
|
cd docker && docker compose up -d --build # local rigs → http://localhost:5320 (start the rigs first)
|
|
# wonder deploy artifact — SELF-CONTAINED, the box has no .NET 10 runtime:
|
|
dotnet publish src/ZB.MOM.WW.Overview/ZB.MOM.WW.Overview.csproj -c Release -r win-x64 --self-contained true -o <out>
|
|
```
|
|
|
|
**2026-10-01 — BTDB Manager registered on all three dashboards.** `appsettings.Wonder.json` (vd03,
|
|
committed) gains one instance `wonder` → `http://127.0.0.1:9876` (management link
|
|
`http://10.220.157.247:9876/`); the QA overlay `E:\ApiInstall\Overview\app\appsettings.QA.json` (deployed
|
|
only, identical on vq03/vq04) gains `vq03`/`vq04` → `http://wonder-app-vq0N.zmr.zimmer.com:9876`. All
|
|
`HasActiveRole: false` (single unclustered Blazor app); `/health/ready` carries one `sql` entry (BT
|
|
reachable). The registry is read at startup only, so `ZbOverview` was restarted on each node (previous
|
|
files kept as `*.bak-20261001T02xxxx`). Verified: vd03 6/6 Up, vq03 and vq04 12/12 Up.
|
|
|