Deploy operator-authenticated alarm ack (488649c+) to DEV/QA after OtOpcUa sends operator_password #170

New Issue

2026-11-06T15:24:55-05:00

dohertj2 commented

2026-11-06 15:24:55 -05:00

The operator-authenticated alarm ack (main 488649c, PR #162, 2026-10-20) changed the contract: AcknowledgeAlarmRequest gained operator_password/operator_domain, and the worker now authenticates as the operator and writes <alarm>.AckMsg. The wonder boxes (DEV wonder-app-vd03, QA vq03/vq04) still run mxgw 4f931e4.

Per the scadaproj index, OtOpcUa's GatewayGalaxyAlarmAcknowledger must send the operator password before it is deployed against this gateway build. A code search of the OtOpcUa checkout (2026-11-06) found no operator_password/OperatorPassword usage, so the consumer side is not ready.

Gateway-side work remaining: once the OtOpcUa change lands, deploy the gateway (Server + x86 Worker built on windev) to DEV, then QA, together with the 2026-10-21 review remediation (see the merge issue), and verify an ack from OtOpcUa is recorded with the real operator in the Historian.

Source: ~/Desktop/scadaproj/CLAUDE.md (mxaccessgw row); docs/superpowers/plans/2026-10-19-ackmsg-as-operator.md; ~/Desktop/scadaproj/deployment.md (deployed mxgw 4f931e4).
Blocked by: OtOpcUa (lmxopcua) acknowledger change.

The operator-authenticated alarm ack (main `488649c`, PR #162, 2026-10-20) changed the contract: `AcknowledgeAlarmRequest` gained `operator_password`/`operator_domain`, and the worker now authenticates as the operator and writes `<alarm>.AckMsg`. The wonder boxes (DEV `wonder-app-vd03`, QA `vq03`/`vq04`) still run mxgw `4f931e4`. Per the scadaproj index, OtOpcUa's `GatewayGalaxyAlarmAcknowledger` must send the operator password before it is deployed against this gateway build. A code search of the OtOpcUa checkout (2026-11-06) found no `operator_password`/`OperatorPassword` usage, so the consumer side is not ready. Gateway-side work remaining: once the OtOpcUa change lands, deploy the gateway (Server + x86 Worker built on windev) to DEV, then QA, together with the 2026-10-21 review remediation (see the merge issue), and verify an ack from OtOpcUa is recorded with the real operator in the Historian. Source: `~/Desktop/scadaproj/CLAUDE.md` (mxaccessgw row); `docs/superpowers/plans/2026-10-19-ackmsg-as-operator.md`; `~/Desktop/scadaproj/deployment.md` (deployed mxgw `4f931e4`). Blocked by: OtOpcUa (lmxopcua) acknowledger change.

dohertj2 added the area:contracts area:worker priority:p2 blocked type:deploy-gate cross-repo migrated labels 2026-11-06 15:24:55 -05:00

dohertj2 referenced this issue

2026-11-06 15:42:10 -05:00

Publish Contracts + Client 0.3.0 (AcknowledgeAlarmRequest operator_password/operator_domain from 488649c) #214

dohertj2 commented

2026-11-06 16:26:06 -05:00

The OtOpcUa side has landed: lmxopcua master dc0a24f2 (closes lmxopcua#749).

GatewayGalaxyAlarmAcknowledger now sends operator_user, operator_domain and operator_password (MxGateway Client/Contracts 0.3.0). The account comes from the API key's Galaxy ack identity, or from the Galaxy driver's AlarmAck fallback account. With neither, the ack is refused and is never sent with an empty operator_user.

⚠️ Order of operations: before this gateway build goes live, the OtOpcUa that talks to it needs (a) this commit deployed and (b) on each Galaxy driver, either an AlarmAck fallback account plus its secret or identities mapped per key. Without one of those, every ack is refused.

I'm leaving this issue open for the gateway DEV/QA deploy and the check that the Historian ACK_ALM row records the operator.

The OtOpcUa side has landed: lmxopcua `master` **dc0a24f2** (closes lmxopcua#749). `GatewayGalaxyAlarmAcknowledger` now sends `operator_user`, `operator_domain` and `operator_password` (MxGateway Client/Contracts **0.3.0**). The account comes from the API key's Galaxy ack identity, or from the Galaxy driver's `AlarmAck` fallback account. With neither, the ack is refused and is never sent with an empty `operator_user`. ⚠️ Order of operations: before this gateway build goes live, the OtOpcUa that talks to it needs (a) this commit deployed and (b) on each Galaxy driver, either an `AlarmAck` fallback account plus its secret or identities mapped per key. Without one of those, every ack is refused. I'm leaving this issue open for the gateway DEV/QA deploy and the check that the Historian `ACK_ALM` row records the operator.

dohertj2 commented

2026-11-06 16:26:47 -05:00

Deploy prerequisites for OtOpcUa (dc0a24f2, lmxopcua#749). Before this gateway goes live on DEV/QA, configure at least one of the following on every OtOpcUa node that runs a Galaxy driver. Without it, every Galaxy ack is refused.

Galaxy driver AlarmAck.FallbackUser, optionally FallbackDomain, and FallbackPasswordSecretRef (e.g. secret:otopcua/galaxy/ack-fallback-password); then create that secret on each driver node.
and/or per-API-key identities on AdminUI /apikeys, stored as otopcua/apikeys/<keyId>/galaxy-ack-user and /galaxy-ack-password. Secrets are per node, so create them on the driver nodes too.

Also note lmxopcua#760: a refused ack currently still returns Good to the OPC UA client.

Deploy prerequisites for OtOpcUa (`dc0a24f2`, lmxopcua#749). Before this gateway goes live on DEV/QA, configure at least one of the following on every OtOpcUa node that runs a Galaxy driver. **Without it, every Galaxy ack is refused.** - Galaxy driver `AlarmAck.FallbackUser`, optionally `FallbackDomain`, and `FallbackPasswordSecretRef` (e.g. `secret:otopcua/galaxy/ack-fallback-password`); then create that secret on each driver node. - and/or per-API-key identities on AdminUI `/apikeys`, stored as `otopcua/apikeys/<keyId>/galaxy-ack-user` and `/galaxy-ack-password`. Secrets are per node, so create them on the driver nodes too. Also note lmxopcua#760: a refused ack currently still returns Good to the OPC UA client.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dohertj2/mxaccessgw#170