Glossary & concepts
ConceptsShort explanations of concepts used across the test plans — networking, storage, secrets management, and more — for anyone who does not work with them every day.
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).
- 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
- 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/…
data/ prefix).secret/ mount, team mounts in TC-OPENBAO-UC-003).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.