PortivoDocs · v2.0.0Complete handbookportivo.orgGitHub
Operations

Operations and command preview

Compatibility-aware bulk command rendering, preview and execution.

v2.0.0Source-backed

Execution sequence

  1. Select action and targets.
  2. Provide any required port, slot, alias or delay parameters.
  3. Preview the exact command plan.
  4. Review compatibility/support evidence.
  5. Optionally use dry-run where the workflow supports simulation.
  6. Run the operation and follow progress in Jobs.

Per-device coordination

A live operation owns one SSH connection and one per-device lease for its complete transaction. No second automated Job or interactive terminal can overtake it on the same switch. Different switches can execute independently under global worker limits.

Configuration persistence

Configuration-changing actions update running configuration first. Pending changes remain visible until explicitly persisted. AOS 8 uses write memory flash-synchro and AOS 6 uses write memory.

Compatibility learning

Explicit command rejection can be learned against the device's profile/model/AOS identity so the same unsupported variant is not repeatedly sent. Configuration-changing syntax is never experimentally probed merely to discover compatibility.

Source-backed detail

Execution transaction and device serialization

Selection, preview and execution are separate stages. The backend resolves the detected AOS family, validates parameters and capability evidence, then renders exact CLI. A Job is created only after authorization and confirmation.

One live operation owns one SSH connection and one per-device lease for its complete transaction. Automated work and interactive terminals targeting the same switch cannot overtake that lease; operations against different switches may continue within bounded parallelism.

Running versus persistent configuration

Configuration changes are recorded as pending instead of being written to flash after every action. Operators explicitly save one switch or all pending switches. The save workflow holds the device lane through flash synchronization, stable-prompt detection and a short cooldown to prevent the next operation racing the save tail.