set_fact, register or inventory? · Ansible

You need a value during a run. You have three places to put it, and the mechanical differences between them are small enough that people choose by habit. The consequences are not small.

This lesson closes Part XIV by putting the runtime sources — facts, register, set_fact — next to the inventory sources from Part XIII, and giving you a test for which one a given value belongs in.

The three, compared

	Inventory (`group_vars` / `host_vars`)	`register`	`set_fact`
Set by	A human, in a file, under review	A task’s result, automatically	A task, from an expression
Precedence	Entries 3–10	Entry 19	Entry 19
Scope	The host or group it names	The host it ran on	The host it ran on
Lifetime	Every run, forever	The rest of this run	The rest of this run, all plays
Visible in `ansible-inventory`	Yes	No	No
Reviewable in a pull request	Yes	The task is; the value is not	The expression is; the value is not

Two rows carry most of the weight.

Precedence. register and set_fact share entry 19, above every inventory source and above play vars. A set_fact silently overrides your group_vars for the rest of the run, and nothing reports that it did. That is enormous power sitting in a task that looks like an assignment.

Reviewable. The inventory row is the only one where a reviewer sees the value. For the other two, a reviewer sees an expression and has to simulate it in their head against a host they cannot see.

Where each one is right

`register`: capturing what a task did

register has no design question attached. If you need to know what a task returned, you register it. The only judgement is whether you needed to run that task at all.

The trap here is the one from the previous lesson wearing different clothes:

Read-only / Safea registered variable is not a fact— Registered variables live for the run and belong to the host the task ran on. Nothing persists them and nothing shares them across hosts unless you go through hostvars.

- name: Read the deployed version
ansible.builtin.slurp:
  src: /opt/app/VERSION
register: version_file

- name: Use it
ansible.builtin.debug:
  msg: "running {{ version_file.content | b64decode | trim }}"

That works on the host the task ran on, in the plays that follow it, in this run. It is not cached, it is not in ansible-inventory, and a different playbook run five minutes later knows nothing about it.

`set_fact`: genuinely deriving something

The legitimate use is a value that is a function of other values, where writing the function once is better than repeating it:

Read-only / Safea defensible set_fact— Computes a value from a fact and a policy variable. The rule lives in one place, the inputs are both visible, and the name says the value was derived.

- name: Derive the worker count from CPUs and the policy ratio
ansible.builtin.set_fact:
  nginx_effective_workers: >-
    {{ [ (ansible_facts.processor_vcpus * nginx_workers_per_cpu) | int,
         nginx_workers_max ] | min }}

- name: Render the configuration
ansible.builtin.template:
  src: nginx.conf.j2
  dest: /etc/nginx/nginx.conf
  mode: '0644'

Three properties make that defensible:

It is derived. processor_vcpus is an observation the controller cannot know in advance, so the value genuinely cannot be written into group_vars.

The policy inputs are in inventory. nginx_workers_per_cpu and nginx_workers_max are decisions, and they live where decisions live. A reviewer can change the policy without reading the arithmetic.

The name declares it. nginx_effective_workers reads as computed. A later reader searching group_vars for it will not find it, and the name is a hint about where to look instead.

Inventory: everything else

If the value is the same on every run, and a person decided it, it belongs in group_vars or host_vars. That is the layering rule from Part XIII and nothing in this part changes it.

The test

One question separates the two cases, and it is worth asking out loud:

Could this value have been written down before the run started?

If yes, it is a decision, and it belongs in inventory. If no — it depends on something only the target host knows — a set_fact is doing real work.

Applying it to four values a real repository contained:

Value	Could it be written down beforehand?	Belongs in
`app_port: 8080` via `set_fact`	Yes. Somebody chose 8080.	`group_vars`
Worker count from `processor_vcpus`	No. Depends on the host.	`set_fact`
`backup_target` chosen by `when: 'prod' in group_names`	Yes. That is a group decision.	`group_vars/prod.yml`
Cluster leader = first host in a group	Yes, but it depends on inventory ordering	Either — see below

The fourth is the honest edge case. A leader election from groups['db'][0] is derived from inventory, so it is reproducible, and it is also fragile in a way that is not obvious: adding a host to the top of a group changes who the leader is, silently. Making it explicit in inventory (db_primary: db01) trades a little duplication for a decision a reviewer can see. Both are defensible; only one of them fails safely when somebody edits the inventory alphabetically.

The pattern that should stop a review

- name: Set the database host
  ansible.builtin.set_fact:
    db_host: db-prod-01.example.com
  when: "'production' in group_names"

- name: Set the database host
  ansible.builtin.set_fact:
    db_host: db-stage-01.example.com
  when: "'staging' in group_names"

Every value here was known before the run. This is group_vars written as task logic, and it costs you four things at once:

ansible-inventory --host web01 does not show db_host, so the diagnostic sequence from Part XIII lesson 3 comes up empty.
The value outranks any group_vars entry someone later adds to override it, so the fix that looks obvious does nothing.
A host in both groups, or in neither, gets whichever branch ran last or no value at all — and “no value at all” surfaces as an undefined error several tasks later.
The environment separation is now in two places, and a new environment means editing tasks rather than adding a file.

The refactor is a group_vars/production.yml and a group_vars/staging.yml, each with one line, and both tasks deleted.

Scope: per host, and that surprises people

set_fact sets the value for the host the task ran on. A play over forty hosts running a set_fact sets forty independent values.

That is usually what you want and occasionally the opposite:

Read-only / Safeone host computes, every host reads— run_once executes the task on a single host. The result is still stored against that host, so other hosts must reach it through hostvars.

- name: Compute the release tag once, on one host
ansible.builtin.set_fact:
  release_tag: "{{ lookup('pipe', 'date -u +%Y%m%dT%H%M%SZ') }}"
run_once: true
delegate_to: localhost

- name: Every host uses the same tag
ansible.builtin.debug:
  msg: "deploying {{ hostvars['localhost'].release_tag }}"

Without run_once, each host computes its own timestamp and forty hosts get forty different release tags — a bug that is invisible until you try to correlate them afterwards.

With run_once and delegate_to, the fact belongs to the delegate. Other hosts read it through hostvars, which means the plumbing is explicit. Delegation has a full part later; the fact-scope consequence belongs here because this is where people first meet it.

Under the hood

set_fact and register occupy the same precedence entry because they are the same mechanism: both write into the host’s variable dictionary at task-execution time, which is what makes them “more recent” than anything loaded at play start.

set_fact has a second mode, and it is why the module is named for facts rather than variables. With cacheable: true it writes two copies — a normal high-precedence host variable and a lower-precedence entry inside ansible_facts that a cache plugin can persist. The consequence covered in lesson 5 bears repeating here because it is a precedence consequence: the value sits at entry 19 in the run that sets it and at entry 11 in every later run, so a value that overrode group_vars on Monday is overridden by it on Tuesday.

There is also no scoping construct for either. Block vars are scoped to a block, task vars to a task, role defaults to a role. A set_fact has no such boundary — once written, it is in that host’s dictionary for the remainder of the run, across every subsequent play. That absence is deliberate (it is what makes cross-play communication possible at all) and it is the reason a naming collision here is a silent wrong value rather than an error.

What happens if a set_fact runs on only some hosts?

The hosts it skipped do not have the variable, and you find out several tasks later.

- name: Set the tuning profile
  ansible.builtin.set_fact:
    tuning_profile: high-throughput
  when: ansible_facts.memtotal_mb > 32000

Hosts with less memory have no tuning_profile at all. The next task that reads it fails on those hosts with an undefined error, and the failure names the reading task rather than the set_fact that did not run — so the traceback points at the wrong line.

Three ways to handle it, in increasing order of how much you should prefer them:

| default('standard') at the point of use. Works, but scatters the fallback across every reader.
An unconditional set_fact whose value is conditional: tuning_profile: "{{ 'high-throughput' if ansible_facts.memtotal_mb > 32000 else 'standard' }}". Every host gets a value. One place to read the rule.
Put tuning_profile in group_vars with the default, and let the set_fact override it only for the exceptional case — so a host that skips the task still has a defined value from the layer below.

Option 3 is the one that composes with everything else in the course: the default is in the layer that exists for defaults, and the runtime computation is an override rather than the only source.

A checklist for review

When you meet a set_fact in someone’s play:

Could the value have been written down beforehand? If yes, it is inventory pretending to be logic.
Is the name prefixed? An unprefixed set_fact is a collision waiting for the run where two roles both use port.
Does every host in the play get a value? If it is conditional, is there a layer underneath supplying a default?
Does it override something? Search group_vars for the name. A set_fact shadowing an inventory variable is either a deliberate emergency override that should be commented, or a bug.
Is cacheable: true there for a reason? If so, does the author know the precedence changes between run one and run two?

Five questions, about thirty seconds, and they catch the two failure modes — the hidden policy decision and the silent override — that otherwise show up as a wrong value in production with no error to trace.

Knowledge check

Why this matters

Part XIII argued that a variable layout is a design with owners and a review path. This part adds the runtime sources, and they are the ones that quietly opt out of that design.

A set_fact is not reviewed the way a group_vars entry is reviewed. Nobody reads a pull request and thinks “that assignment changes the database host for production”. They read a task, it looks like a task, and it goes in. Six months later somebody adds the value to group_vars where it obviously belongs, it has no effect, and an hour disappears into finding out why.

The mechanical rules are short: entry 19, per host, for the run. The judgement is the part worth carrying: a value that a person decided should live where people can see it, and a value that a host reported should be computed where the host is. Getting that boundary right is most of what makes a repository readable a year after you wrote it.