Migration Toolkit Docs

Section 03

Process & Flow

From the operator's first click to the per-AP state machine and the threading model that keeps the UI from freezing.

03

End-to-End Operator Flow

What happens on each click

  1. STEP 1

    Connect to MM

    make_connection()connect()

    SSH to the Mobility Master / controller (or simulation). Runs on a worker thread.

  2. STEP 2

    List APs

    send_command()parse_ap_database()

    show ap database long → AccessPoint rows, each enrich()-ed with family + image.

  3. STEP 3

    Curate List

    add_to_convert_list()

    Filter / multi-select eligible APs into the convert list.

  4. STEP 4

    Choose Strategy

    UpgradeOptions

    Batch-by-model or dynamic per-AP; Central-pull or staged image; dry-run toggle.

  5. STEP 5

    Run Migration

    UpgradeEngine.run()

    Per-AP state machine streams live states + progress to the runner table.

  6. STEP 6

    Export Report

    export_report_csv()

    DONE/FAILED/SKIPPED per AP saved for the change record.

04

Strategy Dispatch — run()

Two best-practice processing models

_run_batch_by_model()

group_by_model() → process all APs of one model, verify the whole group, then advance to the next model. Optional stop_on_group_failure halts the run if a model train misbehaves.

Best for large fleets of identical APs — one image train validated before the next model is touched.

_run_dynamic_per_ap()

Loop the convert list one AP at a time; call ap.enrich() to re-resolve model + image at processing time, then run the same per-AP state machine. No pre-sorting needed.

Best for mixed-model sites — resilient to heterogeneous inventory and newly-seen SKUs.

Both strategies converge on the identical _process_single() state machine, so safety, idempotency, and verification behave the same regardless of the chosen path.

05

Per-AP State Machine — _process_single()

Identical for both strategies

PRECHECK

precheck_ap() + Central idempotency

CONVERTING

convert_ap() → ap convert add-ap

UPGRADING

AP pulls AOS-10 image

REBOOTING

boots into AOS-10

VERIFYING

_verify() via Central

leads to outcome

DONE

AOS10 image installed

FAILED

safe to retry

Safety logic baked in

  • Pre-flight gate — non-AOS-10-capable (e.g. AP-225/215) or down APs are SKIPPED, never sent a convert command.
  • Idempotency — APs already on AOS-10 in Central are SKIPPED.
  • Isolation — one AP failing never aborts the run; it is logged and the loop continues.
  • Verification gate — an AP is only DONE once Central confirms a 10.x build; otherwise FAILED (retryable), never silently passed.
  • Cancellable — _interruptible_wait() checks the cancel flag during long waits.
06

Concurrency Model

Why the UI never freezes

  1. UI THREAD

    Click 'Start'

    run_in_thread()

    Spawns a daemon worker; UI stays responsive.

  2. WORKER

    Engine runs

    UpgradeEngine.run()

    Blocking SSH/REST here. Emits EngineEvents via bus.post().

  3. QUEUE

    WorkerBus

    post() → queue

    Thread-safe hand-off of log / ap_state / progress / done.

  4. UI THREAD

    Drain & render

    after() → drain()

    Updates Treeview rows, progress bar, log console safely.