dohertj2/scadaproj
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

docs(index): vd03 OtOpcUa upgraded to 5fb4b4db (#793); DEV inventory in deployment.md §9

Browse Source
This commit is contained in:
Joseph Doherty
2026-11-12 06:08:08 -05:00
parent 2e2ce62665
commit 1f23e8a965
3 changed files with 15 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude/skills/sister-project-history/otopcua.md
+1 -1
View File
@@ -471,5 +471,5 @@ generated on the box; folder swap, ~11 s downtime. First Windows host on OPC UA
on this box:** FOCAS `Spindle/S1/MaxRpm` → `BadNodeIdUnknown` (renamed `MotorSpeedPct`, tag not re-pointed); macro
`parts-count`/`parts-required` decoded at the right offset; spindle `Load` is a real percent (Float64); unreported program
fields read `BadNoData`. (The vd03 ConfigDb has no Galaxy driver — 1 FOCAS driver only — so the earlier note that
its Galaxy acks fail against mxaccessgw `2b13564e` did not apply to this box's deployed config.) The post-deploy AdminUI deploy (drift = re-serialisation only) is left to the owner. Record:
its Galaxy acks fail against mxaccessgw `2b13564e` did not apply to this box's deployed config.) Post-deploy AdminUI deploy done 11:02 UTC (owner-authorised): deployment `e4b4824a` Sealed, `/fleet` node **Applied** (not degraded), no 3952; the drift was master's composer re-serialising the 2026-08-05 config. New benign log lines: SDK 2 LDS `RegisterServer` retries (`BadServiceUnsupported`), mesh-PSK `ot-mesh-psk-dev` absent (DPS transport, unused). Record:
`docs/deploy/vd03-upgrade-b8b4c18f-to-master.md` §(h).
CLAUDE.md
+3 -2
View File
File diff suppressed because one or more lines are too long
deployment.md
+11
View File
@@ -464,6 +464,17 @@ box under `E:\ApiInstall\<App>\_DEPLOY-NOTES-20260910T*.txt`; ScadaBridge record
11:48–12:22 (§7.1 "Deployed builds on QA"). DEV runs mxgw's Worker rebuilt on windev (the x86 net48
Worker cannot be built on macOS; `ssh windev` is the build box for it).
**DEV has since moved ahead of QA (2026-11-11/12):** ScadaBridge `424db155` (migrations 58→64), mxaccessgw
`2b13564e`, HistorianGateway `ea9f21c` (all 2026-11-11), and OtOpcUa `5fb4b4db` (2026-11-12, #793). The OtOpcUa
upgrade: ConfigDb `OtOpcUaConfig` lives on the app box's own SQL instance (`WONDER-APP-VD03`), not on
wonder-sql-vd03; `EnableSnapshotIsolation` migration applied; `Security__ApiKeys__Pepper` generated on the box
(service env 25 → 26 vars); folder swap with ~11 s downtime; previous install kept at
`E:\ApiInstall\OtOpcUa.bak.20261112-pre-5fb4b4db`, data backup under `E:\ApiInstall\OtOpcUa-backups\`, rollback
script `E:\ApiInstall\_stage-otopcua-5fb4b4db\rollback.ps1`, ConfigDb backup
`OtOpcUaConfig-pre-20261112-otopcua-5fb4b4db.bak` (instance default backup dir). Post-deploy AdminUI deploy
`e4b4824a` → **Applied**; health 200 ×3, ServiceLevel 255. Full record: OtOpcUa
`docs/deploy/vd03-upgrade-b8b4c18f-to-master.md` §(h). QA vq03/vq04 are unchanged from the 2026-09-10 round.
Neither install is a scripted in-repo flow — the operational procedures live in ScadaBridge
`docs/operations/` (`failover-procedures.md`, `maintenance-procedures.md`,
`inbound-api-key-reissue.md`, `troubleshooting-guide.md`). Treat any service/port specifics not in