Execution Strategies

A strategy decides how a fleet of hosts moves through the tasks in a play — whether they march in lock-step or each races ahead on its own. The default, linear, puts a synchronization barrier after every task: every host finishes task N before any host begins task N+1. You change this with one line, strategy: at the play level, and the choice stays invisible until you have enough hosts that the barrier itself is the bottleneck.

There are three strategies worth knowing, and they sit on a spectrum from most synchronized to least. linear is the disciplined default. free drops the discipline for speed. host_pinned is a niche variant of free. The thread running through all of them is that a strategy governs ordering across hosts — and ordering, not raw concurrency, is the thing you reach for a strategy to control.

The linear Strategy

The default linear strategy runs the play one task at a time across the whole batch: every targeted host runs task one, and only when the last host has finished task one does any host start task two. That barrier means the play moves at the speed of the slowest host on every step. It sounds like a cost, and on a large fleet it can be, but it is exactly what you want when a later task assumes an earlier one already finished everywhere.

Concretely, on Larkspur's six prod web hosts, a linear play guarantees that "write the nginx config" has completed on all six before "reload nginx" begins on any of them. No host is ever ahead of the others. That predictability is why linear is the default and why most plays should never change it.

Why the Barrier Exists

The per-task barrier is what makes cross-host ordering reliable. "Configure the db tier, then the web tier" only holds if the web hosts cannot start running while a db host is still mid-migration. Without the barrier a fast host could be three tasks ahead of a slow one, and any assumption that step five sees the result of step two — anywhere in the batch — breaks intermittently and only under load. linear removes that whole class of race by construction.

This is the push model showing its hand. Because the control node drives every host through the same task in step, it can enforce an order across the fleet that a pull model — where each node wakes on its own timer and converges alone — simply cannot express. The barrier is not overhead you tolerate; it is the orchestration primitive the rest of this chapter is built on.

The free Strategy

Setting strategy: free removes the barrier entirely. Each host runs the whole task list as fast as it can and finishes independently, so a host that flies through its tasks does not wait at the end of each one for the stragglers. This is the right call for a large set of identical, independent hosts where the real cost is one slow box holding up the other forty — there is no cross-host ordering to protect, so there is nothing for the barrier to buy.

The example below switches a forty-host log-shipper rollout to free. Every host installs and starts the agent on its own clock; a single slow host finishes late without delaying the rest. Note what this does not do: it does not make the slow host faster, and it does not give you batched waves — it only stops fast hosts from idling at the barrier.

- hosts: log_shippers
  strategy: free          # each host races through its own task list
  become: true
  tasks:
    - name: Install the shipping agent
      ansible.builtin.apt:
        name: vector
        state: present

    - name: Start and enable the agent
      ansible.builtin.service:
        name: vector
        state: started
        enabled: true

The host_pinned Strategy

The host_pinned strategy behaves like free — no barrier — with one difference in scheduling: a worker stays pinned to its host for the whole run rather than picking up whichever host is next free. That keeps each host's work contiguous on a single worker instead of scattered across many. It is a niche choice for fleets where connection setup is expensive enough that the churn of re-pinning matters; on a normal SSH fleet the difference is marginal and the behavior is surprising, so linear or free covers almost every real case.

Strategy Versus Forks

The single most common confusion in this whole area is strategy versus forks, and they are orthogonal. The strategy decides the ordering discipline across hosts — barrier or no barrier. forks decides how many hosts run at once. You can run linear with twenty forks or free with five; the strategy and the concurrency are set independently and answer different questions.

The trap is reaching for a strategy when you actually wanted more parallelism. A linear play feeling slow on sixty hosts usually needs forks raised, not strategy: free — the barrier is rarely the bottleneck until forks is already high. The next topic takes forks and its safety-side cousin serial head on; keep the two knobs separate in your head, because conflating them is how a deploy gets "sped up" by quietly breaking its ordering.