1. Introduction

1.1 What PanCTL Is

PanCTL is the official command-line client for administering a VDURA storage system, invoked as panctl. It is a single, statically linked executable that lets administrators manage realms, storage sets, nodes, tenants, volumes, subnets, users, service accounts, and S3 gateway configuration from a terminal or automation script, without needing the web UI.

PanCTL is organized as a tree of command groups (nodes, volumes, tenants, etc.), each with a consistent set of verbs (list, get, create, update, delete, plus resource-specific actions). Every command supports multiple output formats, including human-readable tables, JSON, and kubectl-style JSONPath, so the same commands work equally well typed interactively or embedded in shell scripts.

1.2 How PanCTL Relates to the API and the Web UI

VDURA systems run a single backend REST service, commonly referred to as PanAPI (the underlying service is vdura-api). Both PanCTL and the VDURA web UI are independent clients of this same API; neither one is “more authoritative” than the other, and neither wraps the other:

• PanCTL → PanAPI directly. Every PanCTL command translates to one or more calls against a documented PanAPI resource (nodes, tenants, volumes, storage sets, and so on). There is no separate “CLI service” in between.
• Same data, same rules, both ways. Because PanCTL and the web UI talk to the same backend, changes made in one are immediately visible in the other. This is most obvious in the observability commands:
  • panctl events list shows the exact same event feed the web UI’s Events view shows.
  • panctl alerts list shows the exact same active-alert set behind the UI’s alert badge.
  • panctl audit list shows the exact same records behind the UI’s Audit Log.
• Live validation, not a stale copy. After you log in, PanCTL downloads a copy of the API’s current OpenAPI specification from the appliance you just authenticated against and caches it locally. Before sending a request that creates or updates something, PanCTL checks your input against that cached specification. This means:
  • Obvious mistakes (a missing required field, a value of the wrong type) are reported instantly, with no network round-trip.
  • If the server’s validation rules change (for example, a field becomes optional), PanCTL picks that up automatically the next time it refreshes its cache; you don’t need to upgrade the CLI to get the new behavior.
  • PanCTL is deliberately permissive when it can’t be sure: if it cannot confirm something is invalid (no cached spec, an unrecognized field, a network hiccup while refreshing), it sends the request anyway and lets the server make the final call.
• Not a superset or replacement. PanCTL does not expose every capability of the web UI (for example, it has no dashboards or visual topology views), and the UI does not expose every flag PanCTL supports (for example, pre-issued API tokens meant for automation). Treat them as two complementary front ends to the same system.

In short: if you can see it in the UI, PanCTL is reading the same record; if you change it with PanCTL, the UI will show the change.