LEARN. PRACTICE. GROW.Once within each batch
The synthetic inventory contains five local-connection aliases using linear strategy and serial=2. The run_once task produces three artifacts: batch-alpha for alpha and beta, batch-gamma for gamma and delta, and batch-epsilon for epsilon. Evidence confirms one execution per batch in this play. It establishes no uniqueness across pipelines or throughout an application’s lifetime. Before placing a migration in such a task, identify whether the requirement is per host, batch, run or persistent. Each requirement needs a different design and supporting evidence.
Host selection is not persistent history
A condition using inventory_hostname == ansible_play_hosts_all[0] produces only single-alpha in the experiment. Documentation explains this distinction from run_once with serial. However, another run or --limit may select a different first host and repeat the operation. For a migration that cannot tolerate duplication, consider the operation’s own history and controls, including concurrency and uncertain-outcome recovery. Compiled inventory order should not be reduced to the first line of a file either. Record the run’s effective selection and state the scope of any uniqueness claim.
Delegate execution and attribute data
In the lab, alpha executes set_fact with delegate_to: beta. Without delegate_facts, the marker belongs to alpha. With delegate_facts: true, the second marker belongs to beta. A task’s position in output is insufficient to identify the data’s owner. For a delegated check, distinguish original host, operation destination and observed identity. Read hostvars from the correct owner and review which variables feed parameters. The experiment uses local assignments, not SSH fact gathering or health checks against remote servers, and cannot establish either of those outcomes.
Clear_facts and the variable that remains
The set_fact task with cacheable=true creates representations with different precedence. Before clear_facts, the lab also observes lab_marker within ansible_facts. Afterward, that representation disappears, but the host variable still resolves to retained-host-variable. No external or persistent cache backend was configured. The result needs no such mechanism and establishes no persistence between processes. If a gate depends on previously stored readiness, reading the variable does not rerun the original check. Obtain a fresh observation when the progression criterion requires current evidence about the target.
Parallelism and progression scope
Delegating several tasks to the same destination does not automatically serialize concurrent writes there. Review concurrency, artifact names and the actual operation before assuming safety. Similarly, serial limits hosts handled in each batch, but neither drains traffic nor confirms remaining capacity. The lab has five aliases on one machine; they are not five independent servers. A real change needs specific controls for traffic, capacity, health and recovery. The serial value contributes to the plan but does not by itself establish availability throughout the change.
Gate workshop with identity and time
In the fictional case, a value intended to represent beta is assigned to alpha and used as the latter’s current readiness. Hold progression and reconstruct observation source, owner, time and criterion. Correct the structure so each result preserves its corresponding identity. Copying true to both hosts merely spreads the claim without obtaining evidence. At handover, also record host selection and completed batches. Communicate: “The stored value does not establish current readiness for this target.” Identify who will collect the missing observation and what result permits progression.
With five aliases and serial=2, run_once generated three batch markers. After clear_facts, ansible_facts lost lab_marker, but the host variable remained available in the same run.
Common pitfalls
Interpreting run_once as a global lock; assuming delegate_to serializes tasks; confusing aliases with machines; using a retained fact as current evidence; expecting persistence from cacheable=true alone.
Related topics: Tasks and desired state · Batch orchestration · Failures and recovery
Associate each execution and datum with its scope. Batch, host, process and persistent history are different dimensions that need their own supporting evidence.
Reference: Controlling playbook execution: strategies and more · Ansible community 14 / ansible-core 2.21 documentation consulted 2026-09-30; executor, collection and plugin compatibility requires confirmation