Control Node Host Filtering versus Managed Node Task Strategy for Low-Traffic Ansible Cost Reduction

Answer

--limit defines a static host subset before the play starts; strategy:free then runs tasks on those hosts as soon as each host finishes its current task, limited only by the fork setting. The combination gives parallelism exclusively to the limited hosts, so excluded hosts incur no control‑node overhead but will be missed unless the limit is refreshed. Selecting tasks with tags after host selection lets you run only needed work on the filtered hosts without duplicating tasks.

Confirmed facts

• --limit restricts the inventory to a static set before play execution; hosts outside the set are never contacted.
• strategy:free tells Ansible to dispatch tasks as soon a node finishes its current task, removing the linear host‑order barrier and allowing parallelism up to the fork limit.
• Tag evaluation occurs after host selection and before task dispatch, so tags do not cause duplication across hosts.

Likely explanation

For sporadic workloads, a dynamic --limit (e.g., generated by an inventory script that picks currently active hosts) reduces control‑node CPU and network traffic because only active hosts are contacted. Adding strategy:free further cuts wall‑clock time by avoiding straggler waits, provided the controller has sufficient fork capacity. Tags such as tags: [monitor, update] let operators run only the required subset of tasks on the filtered hosts, preventing duplicate execution while still covering intermittent hosts when the limit is refreshed.

Steps for this case

1. Use an inventory script that returns only hosts currently marked as active (e.g., via a health check or a flag in a database).
2. Invoke the playbook with --limit "$(inventory-script)".
3. In the playbook, set strategy: free at the play level.
4. Choose a fork value that matches the control‑node’s CPU/memory capacity (start with the default and monitor).
5. Apply relevant tags to tasks and run with --tags monitor,update (or whichever tags you need).
6. Re‑run the playbook periodically or trigger it when the active‑host set changes to refresh the limit.

Missing diagnostic detail

To confirm that strategy:free will not increase control‑node overhead, please provide the current fork setting and the observed control‑node CPU usage during a baseline run without --limit or strategy:free. This information determines whether raising the fork count for parallelism is advisable.