Ansible data validation

Validating data before Ansible touches a host — catching malformed host_vars, wrong types, and broken referential integrity at commit time instead of mid-playbook at 2 a.m. Anchored on ipspace.net’s validation pipeline (both articles captured 2026-10-07).

The three validation layers (ipspace’s pipeline)

1. Text file syntax — YAML well-formedness: yamllint in git hooks / CI. The cheapest layer; catches everything from tabs to duplicate keys.
2. Conformance with a data-model schema — structure, required fields, types: JSON Schema via jsonschema. YAML → JSON is trivial, so JSON Schema covers Ansible host_vars/group_vars/network.yml alike. Example constraints from their data model: every host has hostname + bgp_as; links is an array of core/edge links; core links carry prefix + ≥2 more values; edge links are a single dict.
3. Referential integrity — cross-file references (does that bgp_as neighbor actually exist?): usually beyond schema languages; a small custom program, “but at least you can offload the boring task of checking data structures and format to a third-party solution.”

The tooling

• ansible.utils.validate module (ipspace’s 2021 article, captured): pass data + JSON Schema + engine (jsonschema) → success or an error list. Replaced the older hand-rolled assert/jsonschema-in-command tricks.
• ansible-inventory --list | jq ._meta.hostvars — the canonical way to feed all host_vars (multi-file, script-generated, plugin-generated) into a validator as one JSON blob. Works in hooks and CI without running a playbook.
• CI/hook placement: same checks run as git commit hooks (ipspace’s own setup) and in pipelines — validate before the playbook ever starts.

The honest box (ipspace’s own warning)

jsonschema error messages “could be a bit counter-intuitive… trying to decipher what exactly you did wrong from the error message is a bit of a chore (hope you noticed how extremely polite I tried to sound — sometimes it’s a ******* nightmare).”

And once Ansible wraps a failed module’s output in its own JSON, you get “a perfect puzzle to keep you awake all night when your playbook crashes on bad data at 2AM on a Sunday morning.” Mitigation: ANSIBLE_STDOUT_CALLBACK=yaml before troubleshooting failed validation output.

Why it matters (the doctrine)

• Fail at the boundary: data errors are cheapest at commit time (hook < CI < playbook-run < mid-change production). This is Golden Path’s guardrail applied to data rather than code, and the same “preconditions as filters” discipline as Uber’s migration recipes (Software engineering in AI era).
• Data models are contracts: schema validation makes host_vars/group_vars an interface, not folklore — the precondition for anything generating or refactoring inventory data (agents included; a schema is machine-checkable ground truth for LLM-written vars).
• COT relevance: ps-ansible’s inventory-heavy playbooks fit this exactly — the pipeline is yamllint + JSON Schema on host_vars/network data + ansible.utils.validate in a pre-run check play, before any change task.

Vault kin

• Ansible — the hub; ansible-role-cot-acl the role-notes lane
• Rewriting Ansible roles from K8s operators — desired-state discipline this complements
• LLM evals — deterministic checks as the floor of any eval ladder; schemas are the data-shaped instance
• Supply Chain Security — same trust-boundary thinking, applied to config data

The origin post: operational state management + remediation (captured via Wayback)

The Red Hat announcement itself (Wayback snapshot 20241109012747; live page gone/JS-shell; 11.5 KB captured) — the post ipspace’s article was thanked in. It adds the runtime half the ipspace pipeline leaves out: validation isn’t only for input data (host_vars before a change) but for live operational state — collect (e.g. cli_backup/facts → normalized structured JSON) → define desired state as a jsonschema criteria file (admin_state: pattern "up" for all interfaces) → ansible.utils.validate current vs desired → remediate → re-validate. The full loop: input-data validation before the change, state validation after it, corrective action on deviation — drift detection with the same schema tooling, not a separate product. Wiring note: this closes the loop with Rewriting Ansible roles from K8s operators’ reconciliation idea — desired-state criteria as JSON Schema is a lightweight reconcile primitive.

The talk: FOSDEM 2021 “State assessment and data validation using Ansible” (captured with transcript)

Ganesh Nalawade, FOSDEM 2021 (TIB AV-Portal, DOI 10.5446/53638, CC BY 2.0 BE; 259-cue Whisper transcript extracted from the page’s API and appended to the clipping — the video-native version of the Red Hat post above): the live-demo walk of the whole loop — cli_backup/facts → structured JSON → criteria file → ansible.utils.validate → remediation playbook → re-validate — demonstrated for Linux hosts and network appliances (the network angle is the talk’s added value: NXOS interface state as the worked example). Also the source of the “provide host_vars as the validate module’s data key” pattern — input-data validation and operational-state validation in one module.