Format:
Export:

Glossary & concepts

Concepts

Short explanations of concepts used across the test plans — networking, storage, secrets management, and more — for anyone who does not work with them every day.

macvtap (NOT supported) vs. OVN-K localnet (official path)
macvtap gives a VM its own MAC — but is NOT officially supported in OpenShift Virtualization. The correct approach is OVN-K localnet.
WaitForFirstConsumer (StorageClass binding mode)
A PVC stays deliberately 'Pending' until a pod/VM actually uses it — not an error!
NodeNetworkConfigurationPolicy (NNCP)
Declarative node network configuration via the Kubernetes API — instead of manual nmcli commands.
OVN-Kubernetes & br-ex
OpenShift's default network plugin uses an OVS bridge (br-ex) that takes over the physical NIC.
HCP: does every hosted cluster need its own public IP?
No — only the API server (with the KubeVirt/on-prem provider) needs a dedicated IP or dedicated port. OAuthServer, Konnectivity, and Ignition already share the management cluster's existing Ingress route today.
Sealed vs unsealed — why pods stay 0/1 Ready
A sealed OpenBao holds only encrypted data and refuses almost every request — the pod runs but is not Ready. Unsealing reconstructs the barrier key.
KV v2 — versions, soft delete, and check-and-set (CAS)
KV v2 keeps a version history per secret and can require a version number on every write — a write is a whole new version, not a field update.

Unlike KV v1, every bao kv put on a v2 mount creates a new version of the complete secret. Old versions stay readable (-version=N), can be soft-deleted and undeleted, or destroyed permanently. With cas_required (TC-OPENBAO-KV-002), each write must state the version it is based on (-cas=N); if someone else wrote in between, the write fails instead of silently overwriting — the same idea as optimistic locking. The most common surprise: a put replaces the entire key set, so updating only one field drops the others (this is exactly the ESO sync pitfall in TC-OPENBAO-INT-001).

✓ ADVANTAGES
  • Version history gives rollback for free (TC-OPENBAO-KV-003 rotation pattern)
  • CAS prevents lost updates from concurrent writers such as CronJobs
  • Soft delete is recoverable — destroy is the only irreversible step
⚠ LIMITATIONS
  • Writes replace the whole secret — always send every field
  • CAS-enabled paths break naive scripts that write without -cas
  • Policy paths change: data lives under <mount>/data/…, metadata under <mount>/metadata/…
COMPARISON
KV v1: No versions, no CAS — a put overwrites permanently. Simpler policies (no data/ prefix).
KV v2: Versioned, CAS-capable. Used everywhere in this plan (secret/ mount, team mounts in TC-OPENBAO-UC-003).
📍 WHY IT MATTERS HERE

TC-OPENBAO-KV-001 walks through versioning and delete/undelete, TC-OPENBAO-KV-002 enables cas_required, TC-OPENBAO-KV-003 builds a CAS-safe rotation CronJob, and TC-OPENBAO-INT-001 hits both the cas_required and the 'update all fields' pitfalls when ESO syncs.

Kubernetes auth method — SA token in, OpenBao token out
Pods authenticate with their projected ServiceAccount JWT; OpenBao validates it against the kube-apiserver and returns a short-lived token carrying the role's policies.
OpenBao vs Vault — why /vault/ still appears everywhere
OpenBao is the Linux Foundation fork of HashiCorp Vault and keeps API and tooling compatibility — so UI routes, sidecar paths, and third-party integrations still say 'vault'.
Raft integrated storage — leader, quorum, snapshots
OpenBao stores data itself and replicates it with the Raft consensus protocol — no external database, but quorum rules apply.

Search test plan

Type at least 2 characters to search

Keyboard shortcuts

P
Go to prerequisites
T
Go to test cases
G
Go to glossary
D
Go to diagrams
J
Next card
K
Previous card
Enter
Open / close focused card
/
Open search
CtrlK
Open search modal
?
Show shortcuts
Esc
Close panel / blur search