Skip to main content

Change Planner

zorvia plan turns Drift Guard findings into a conservative operational execution plan: what can change online, what needs a restart, what requires recreate, and what needs manual review.

It does not apply changes. Use it for change windows, CI gates, and operator review before you mutate the cluster.

Why plan after drift​

ToolJob
zorvia driftSemantic desired-vs-live (or file-vs-file) diff with severity
zorvia planTurn those findings into downtime-aware steps

The planner assumes CPU/memory and network changes need a controlled restart unless you have confirmed hotplug support. Storage-source, firmware, machine-type, and TPM changes require recreation or explicit review.

Examples​

# Offline desired-vs-actual planning
zorvia plan desired.yaml --actual live-capture.yaml

# Plan against the live cluster
zorvia --namespace production plan desired.yaml --vm payments-01

# CI gates
zorvia plan desired.yaml --actual current.yaml --fail-on-downtime
zorvia plan desired.yaml --actual current.yaml --fail-on-recreate

# Machine-readable output
zorvia plan desired.yaml --actual current.yaml -o json
zorvia plan desired.yaml --actual current.yaml -o yaml

Typical plan shape​

Plans group steps by risk class:

  1. Online — metadata / labels that can apply without stopping the VMI
  2. Restart — capacity or network topology that needs a controlled stop/start
  3. Recreate — disks, volumes, firmware, machine type, TPM
  4. Manual review — ambiguous or high-blast-radius findings

Use --fail-on-downtime or --fail-on-recreate in CI when a PR must not introduce restart/recreate work without review.

Workflow​

# 1. Capture drift
zorvia drift desired.yaml --vm payments-01 -o json > drift.json

# 2. Build an execution plan
zorvia plan desired.yaml --vm payments-01 -o json > plan.json

# 3. Apply only after review (CLI create/start/stop, web console, or GitOps)