Jon Vanvik
80fd7e8d37
Adds a second bulk workflow alongside the firmware upgrader: changing PON flooding mode (private<->auto) on OLT NNI services across many OLTs. Flooding mode is encoded by the presence of the "PON FLOOD ID" key on each OLT-CFG["NNI Networks"] entry (present = private, absent = auto). private->auto deletes the key; auto->private sets it to 0. The rest of the OLT-CFG is preserved (PUT-as-replace, same as ONU-CFG). - src/mcms-api.js: listAllOltConfigs / getOltConfig / putOltConfig, plus pure helpers floodModeOfNni, summarizeOltNniNetworks, planFloodChange (planFloodChange clones and never mutates its input) - main.js: api:listOlts + api:executeFloodChange IPC handlers (concurrency 3, GET->plan->PUT, streams olt-flood:progress) - preload.js: expose both channels + onFloodProgress - renderer: OLT inspector view (#view-olts), two-step APPLY confirm, auto-saved pon-olt-flood-*.csv result report - Restore README.md (lost to a filesystem error) and document the new feature in README.md and CLAUDE.md (new section 14) Verified: npm run check passes; pure helpers unit-tested for the no-mutation, idempotency, and rollback invariants. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
143 lines
5.5 KiB
Markdown
143 lines
5.5 KiB
Markdown
# PON Fleet Upgrader
|
|
|
|
An Electron desktop app for bulk operations against a **Ciena
|
|
MicroClimate Management System (MCMS) 6.2** PON Manager. It does two
|
|
things:
|
|
|
|
1. **Bulk ONU firmware upgrades** (below).
|
|
2. **Bulk OLT PON flooding-mode changes** (private↔auto on NNI services —
|
|
see "OLT PON flooding mode" 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 PON flooding mode
|
|
|
|
From the fleet view, **Open OLT inspector…** opens a second workflow for
|
|
bulk-checking and changing the PON flooding mode of OLT NNI services.
|
|
|
|
On Tibit OLTs the flooding mode is 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` |
|
|
|
|
Workflow: enter a **TAG MATCH** pattern (exact like `s0.c76.c0`, or a `*`
|
|
glob like `s0.c76.*`), **Load OLTs**, select the OLTs to change, pick a
|
|
direction, then **Execute change…** (two-step confirm). Each OLT is
|
|
re-fetched, the matching NNI entries are flipped, and the full OLT-CFG is
|
|
PUT back. A result CSV is auto-saved to `~/Downloads/pon-olt-flood-*.csv`.
|
|
|
|
Both directions are supported, so a change can be rolled back from the same
|
|
screen. The default action targets `s0.c76.c0`, `private` → `auto`.
|
|
|
|
## 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.
|