Choosing Between Linear and Free Execution Strategies in Ansible

The Synchronization Bottleneck

When running Ansible playbooks against large inventories, a single slow server or a lagging network connection can stall your entire deployment. By default, Ansible uses the linear strategy, which forces every host to complete Task A before any host can begin Task B. While this ensures consistency, it often leads to wasted idle time on high-performance nodes.

The decision between linear and free strategies depends on whether your deployment requires cluster-wide synchronization or maximum throughput.

Comparison of Execution Strategies

Feature	Strategy: Linear (Default)	Strategy: Free
Host Progression	Synchronized; all hosts move together.	Independent; hosts move at own pace.
Execution Speed	Limited by the slowest host.	Limited by slowest single-host path.
Consistency	High; guaranteed state across inventory.	Low; hosts may be at different stages.
Log Readability	Sequential by task.	Interleaved by host.

Trade-offs and Decision Logic

When to use Linear

Use the linear strategy when tasks have cross-host dependencies. For example, if you are updating a database schema on a primary node and then updating application code on web servers, the web servers must not proceed until the database migration is confirmed successful across the board.

Linear is also essential for rolling updates where you need to verify the health of a batch of servers before moving to the next set to avoid total service downtime.

When to use Free

The free strategy is ideal for "embarrassingly parallel" tasks—operations where the state of Host A has no impact on Host B. Examples include updating OS packages, configuring local timezones, or deploying static assets to a fleet of independent web nodes.

By removing the synchronization barrier, you eliminate the "bottleneck effect," where one unresponsive server halts the entire pipeline for hundreds of other healthy nodes.

Implementation and Validation

The strategy is defined at the playbook level in the YAML header. This setting applies to all plays within that specific playbook file.

Example Configuration

# playbook.yml
- name: Optimize independent node configuration
  hosts: web_servers
  strategy: free
  tasks:
    - name: Update system packages
      ansible.builtin.yum: 
        name: '*'
        state: latest
    - name: Configure local application settings
      ansible.builtin.template:
        src: config.j2
        dest: /etc/app/config.conf

How to Validate the Behavior

To verify which strategy is active, you can introduce a deliberate delay on a subset of your hosts. Run this on a control node with sudo permissions for the target hosts:

1. Create a test playbook with strategy: linear.
2. Add a task using the ansible.builtin.pause module that only triggers on one specific host (using when: inventory_hostname == 'slow-node').
3. Run the playbook. If other hosts stop and wait for the paused host to finish before moving to the next task, the linear strategy is working.
4. Change the header to strategy: free and repeat. You should observe the healthy hosts completing the entire playbook while the slow node remains paused.

Limitations and Risks

• Race Conditions: Using free strategy with tasks that depend on a shared resource (like a shared NFS mount or a single API endpoint) can lead to race conditions.
• Log Confusion: In free mode, Ansible output is not grouped by task. This makes debugging specific task failures across the fleet more difficult as the output is interleaved.
• Wait-for Logic: The wait_for module may behave unpredictably in free mode if it is intended to wait for a service to start on a different host.

Rollback

To revert to default behavior, remove the strategy: free line from the playbook header or explicitly set it to strategy: linear.