Ansible Cacheable set_fact Design Prompt
Design cacheable set_fact and registered facts with clean namespacing so reruns are fast and deterministic instead of recomputing everything every play.
- Target user
- Engineers whose playbooks recompute expensive facts on every run and want safe, namespaced caching
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior Ansible engineer who treats facts as state that lives longer than a single play. You know that `set_fact` with `cacheable: true` writes into the fact cache and persists across plays and runs, and that careless caching produces stale, surprising values that are worse than no caching at all. I will give you a set of tasks that compute or register facts. Redesign them so the expensive ones are cached safely and the volatile ones are not. Steps: 1. **Classify each fact**: mark it as stable (safe to cache across runs), per-run (recompute each run, do not cache), or secret (must never be cached or logged). 2. **Namespace the facts**: wrap related facts under a single dict variable (e.g. `myapp_facts.db_host`) instead of polluting the top-level namespace, and explain the precedence implications. 3. **Apply `cacheable: true` only to stable facts**, and show the matching fact-cache config (`fact_caching`, `fact_caching_connection`, timeout) in `ansible.cfg`. 4. **Guard staleness**: for each cached fact, state how it is invalidated or refreshed, and add a `--flush-cache` note for forced recompute. 5. **Protect secrets**: ensure any task touching credentials uses `no_log: true` and is never marked cacheable. 6. **Idempotency check**: confirm a second run reuses cached stable facts and still recomputes per-run ones. Fill in: - Tasks / facts to redesign: [PASTE TASKS] - Fact-cache backend in use or planned: [jsonfile / redis / memory / none] - Which facts are credentials or tokens: [LIST OR "none"] Output format: the rewritten tasks YAML with namespaced cacheable/non-cacheable facts, the `ansible.cfg` cache stanza, a table classifying each fact (stable/per-run/secret + cacheable yes/no + invalidation), and a short note on when to run `--flush-cache`. Do not run anything. Recommend testing on one host with `--check` where the tasks support it, then a single real run, inspecting the fact cache contents before trusting cached values fleet-wide.
Why this prompt works
Caching facts is one of those optimizations that quietly turns into a bug source. A set_fact with cacheable: true does exactly what you ask: it persists the value to the fact cache so future plays and even future runs skip the work. The trouble is that “skip the work” also means “keep the old answer,” and an engineer who caches a value that should have been recomputed gets a stale fact feeding silently into a deploy. This prompt forces the first and most important decision up front — classify every fact as stable, per-run, or secret — so caching is applied deliberately rather than sprinkled on for speed.
The namespacing step matters more than people expect. Dumping a dozen set_fact results into the top-level variable namespace creates precedence collisions that are miserable to debug, especially once those facts are cached and outlive the play that created them. Wrapping them under a single dict keeps the cache tidy and the precedence predictable, and it makes a --flush-cache reset comprehensible instead of a guessing game.
The guardrails reflect the two ways fact caching actually hurts teams: stale data and leaked secrets. Cached facts live on disk or in Redis in readable form, which means a credential marked cacheable bypasses the no_log scrubbing you carefully added elsewhere. By demanding an explicit invalidation path for every cached value and refusing to cache anything secret, the prompt keeps a genuine performance win from turning into a correctness or security incident.