Jon Vanvik
5e3d9271a8
Generalises the OLT bulk tool from flood-mode-only to arbitrary NNI-service
edits. DHCP modes live nested under each NNI entry's Filter object
(Filter.DHCPv4 / Filter.DHCPv6, e.g. "pass" <-> "umt"), confirmed from a
real OLT-CFG paste-back.
- src/mcms-api.js: planFloodChange -> planNniEdit(oltCfg, {tagPattern, flood,
dhcpv4, dhcpv6}); each concern optional. DHCP is value-replacement,
replace-only-when-present (never invents the key; leaves EAPOL/PPPoE/NDP).
Still non-mutating (clones the entry AND the Filter). Returns changes with
per-entry edits[]. summarizeOltNniNetworks surfaces dhcpv4/dhcpv6; new
dhcpModeOfNni helper.
- main.js + web/server.js: executeFloodChange handler passes flood/dhcpv4/
dhcpv6 ops through (channel name kept for wire compat).
- renderer: OLT inspector now has three action dropdowns (Flooding / DHCPv4 /
DHCPv6, defaults flood private->auto + DHCP pass->umt); table shows DHCP
chips + per-service "will change (flood, DHCPv4, …)"; flood-mode filter
defaults to Any so DHCP-on-pass auto-flood OLTs still show; CSV report
lists every per-NNI edit (pon-olt-nni-*.csv).
Verified: node --check; planNniEdit unit-tested against the real fixture +
a pass variant (13/13: no-mutation, EAPOL/PPPoE/NDP preserved,
replace-when-present, flood/DHCP independence); OLT view rendered offscreen
showing correct per-service "will change" markers.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
155 lines
6.3 KiB
Markdown
155 lines
6.3 KiB
Markdown
# PON Fleet Upgrader
|
|
|
|
An Electron desktop app for operating a **Ciena MicroClimate Management
|
|
System (MCMS) 6.2** PON Manager. Top tabs split it into:
|
|
|
|
1. **Dashboard** — read-only network telemetry: ONU/OLT/controller counts,
|
|
aggregate up/down traffic, health (abnormal Rx, lasers off), and ONU
|
|
registration-state breakdown (with an opt-in per-ONU Rx/FEC scan).
|
|
Clicking a state jumps to the ONU tab pre-filtered.
|
|
2. **ONU** — the fleet table plus **bulk ONU firmware upgrades** (below).
|
|
3. **OLT** — **bulk OLT NNI-service edits**: PON flooding mode (private↔auto)
|
|
and DHCPv4/v6 filter (pass↔umt) — see "OLT NNI-service edits" below.
|
|
|
|
## ONU firmware upgrades
|
|
|
|
Filters a fleet of ONUs, previews the planned writes, and stages new
|
|
firmware to each device's **inactive bank** so the forced reboot is
|
|
deferred until the next natural restart window.
|
|
|
|
Two execution modes:
|
|
|
|
- **Bulk task (Procedure 8, recommended)** — creates a single
|
|
`AUTO-TASK-CFG` via `PUT /v3/tasks/configs/<id>/`. MCMS owns the rollout
|
|
(retries, pacing, scheduled start).
|
|
- **Per-ONU PUT (Procedure 7)** — iterates the selected ONUs, fetches each
|
|
`ONU-CFG`, mutates `FW Bank {Ptr,Files,Versions}`, and `PUT`s the full
|
|
document back. Slower, but you see errors live per device.
|
|
|
|
## Prerequisites
|
|
|
|
- Node.js 18+ and npm
|
|
- Network reachability to your MCMS host
|
|
- An MCMS user with ONU write + Files write permissions
|
|
- A compatible ONU firmware `.bin` file (already uploaded via this tool
|
|
or the vendor UI into `/files/onu-firmware/`)
|
|
|
|
## Install & run
|
|
|
|
```bash
|
|
cd pon-fleet-upgrader
|
|
npm install
|
|
npm start
|
|
```
|
|
|
|
This launches an Electron window. Use `npm run check` to syntax-check all
|
|
source files without launching the app.
|
|
|
|
## Bank strategy
|
|
|
|
MCMS stores firmware in two slots per ONU (`FW Bank Files[0/1]`,
|
|
`FW Bank Versions[0/1]`) with `FW Bank Ptr` pointing at the active one.
|
|
|
|
| Current `FW Bank Ptr` | Tool writes to slot | Why |
|
|
|-----------------------|---------------------|-----|
|
|
| `0` | `1` | Don't overwrite active image |
|
|
| `1` | `0` | Don't overwrite active image |
|
|
| `65535` (unset) | `1` | Matches Procedure 7 example; slot 0 stays as factory fallback |
|
|
|
|
The tool computes this per ONU and buckets the selection by target slot
|
|
when submitting a bulk task (MCMS's `AUTO-TASK-CFG.Task Details.ONU.FW
|
|
Bank Ptr` accepts a single slot number, so each bucket becomes one task).
|
|
|
|
## Safety notes
|
|
|
|
- **Always validate on one ONU first.** Select a single device, run in
|
|
per-ONU mode, confirm the ONU recovers on slot N before using bulk
|
|
task on the rest of the fleet.
|
|
- **Don't blank the active slot.** The planner preserves both slots'
|
|
existing `Files`/`Versions` and only writes the target slot.
|
|
- **Scheduled start is UTC.** The datetime-local picker converts from
|
|
your local timezone to UTC before submitting the `AUTO-TASK-CFG`.
|
|
- **Leave the session short.** Log out when done — MCMS sessions don't
|
|
auto-expire and a stale cookie on a shared workstation is an
|
|
unnecessary exposure.
|
|
|
|
## Filters
|
|
|
|
The left panel supports:
|
|
|
|
- **Name / address contains** — substring match over
|
|
`ONU.Name`, `ONU.Address`, and `_id`
|
|
- **PON mode** — server-side Mongo filter on `ONU.PON Mode`
|
|
- **Active version matches** — substring match on the version string in
|
|
whichever slot `FW Bank Ptr` points to
|
|
- **Model / version family** — substring match across *both* slots'
|
|
version strings, useful for fleet cuts like `EV051` (all Everest 5.1x)
|
|
|
|
The server-side projection is narrow (serial, name/address, PON mode, bank
|
|
state). The full ONU-CFG is only re-fetched at plan time.
|
|
|
|
## Files
|
|
|
|
```
|
|
pon-fleet-upgrader/
|
|
├── package.json
|
|
├── main.js # Electron main process, IPC handlers
|
|
├── preload.js # contextBridge exposing window.api.*
|
|
├── src/
|
|
│ ├── mcms-api.js # HTTPS client with tough-cookie jar + CSRF
|
|
│ └── bank-strategy.js # inactive-bank selection + plan computation
|
|
└── renderer/
|
|
├── index.html # Login / fleet / campaign views
|
|
├── app.css
|
|
└── app.js # UI logic
|
|
```
|
|
|
|
## OLT NNI-service edits
|
|
|
|
From the fleet view, **Open OLT inspector…** opens a second workflow for
|
|
bulk-checking and editing OLT NNI services. Two independent edits can be
|
|
applied together to every matching service:
|
|
|
|
**Flooding mode** — encoded by the presence of a single key on each
|
|
`OLT-CFG["NNI Networks"]` entry:
|
|
|
|
| Mode | `PON FLOOD ID` key | Change |
|
|
|------|--------------------|--------|
|
|
| **private** | present (any value, incl. `0`) | → auto: delete the key |
|
|
| **auto** | absent | → private: set the key to `0` |
|
|
|
|
**DHCP filter mode** — values nested under each entry's `Filter` object
|
|
(`DHCPv4` / `DHCPv6`), e.g. `pass` ↔ `umt`. Only entries that already have
|
|
the field are touched (the field is never invented); `EAPOL`/`PPPoE`/`NDP`
|
|
are left alone.
|
|
|
|
Workflow: enter a **TAG MATCH** pattern (exact like `s0.c76.c0`, or a `*`
|
|
glob like `s0.c76.*`), **Load OLTs**, pick any of the three actions
|
|
(Flooding / DHCPv4 / DHCPv6), select the OLTs — each matching service shows
|
|
"→ will change (…)" for the edits that apply — then **Execute changes…**
|
|
(two-step confirm). Each OLT is re-fetched, the matching NNI entries are
|
|
edited in one pass, and the full OLT-CFG is PUT back. A result CSV is
|
|
auto-saved to `~/Downloads/pon-olt-nni-*.csv`.
|
|
|
|
All directions are supported (e.g. `umt → pass`), so changes roll back from
|
|
the same screen. Defaults: `s0.c76.c0`, flood `private → auto`, DHCPv4/v6
|
|
`pass → umt`.
|
|
|
|
## Known limitations
|
|
|
|
- The `/v1/onus/<id>/upgrade/status/` path used by the original question
|
|
isn't part of the dev-guide-documented surface; if your MCMS returns
|
|
404 for it, fall back to polling `GET /v1/onus/configs/<id>/` and
|
|
watching `FW Bank Versions` + `FW Bank Ptr` change.
|
|
- Progress of a bulk task is reported back by MCMS in its own task
|
|
status collection — the tool currently submits and then leaves
|
|
monitoring to the PON Manager UI. Follow-up work: poll
|
|
`/v3/tasks/states/<taskId>/`.
|
|
- No offline mode / cached fleet snapshot. Each `Load fleet` hits the
|
|
API.
|
|
- PATCH endpoints aren't used — MCMS requires full-document PUTs for
|
|
`ONU-CFG` updates (the dev guide is explicit about this).
|
|
|
|
## License
|
|
|
|
Internal use only.
|