Ansible / Advanced: orchestration, platforms, tests, and diagnosis / Lesson 15

Design rolling changes with capacity and stop conditions

Separate serial batches, forks, strategy, throttle, async behavior, health gates, and failure budgets in an operational rollout plan.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain concurrency controls at their actual scopes.
Define capacity and application acceptance between batches.
Interpret failure thresholds without assuming rollback or atomicity.

Concurrency controls solve different scheduling problems

serial divides a play’s hosts into batches, while forks controls available worker concurrency and throttle can restrict particular task execution under documented limits. A strategy determines how hosts advance through tasks; linear and free have different coordination behavior. These controls are not interchangeable ways to set one global parallelism number. A task delegated to a shared resource can still need another ownership policy. Read the active strategy plugin and effective configuration before predicting order. A rollout design should state which work may overlap and which barrier must hold before the next population proceeds.

A batch size consumes failure and service headroom

Removing or changing several nodes at once can reduce serving capacity before the automation reports a failure. Choose a batch from measured application demand, redundancy, dependency capacity, and the tolerated failure scenario, not from a fashionable percentage. A healthy process is not necessarily ready to serve traffic. Define drain, apply, validate, activate, health, and return-to-service milestones where relevant, with explicit stop conditions. This course never performs those actions. It illustrates the plan so an authorized operator can review whether remaining capacity and recovery paths are sufficient.

Failure thresholds have exact comparison semantics

any_errors_fatal and max_fail_percentage influence continuation under their documented scopes; neither implements application rollback. In the documented max_fail_percentage model, the threshold must be exceeded rather than merely reached. Interpret it with the current batch and actual host outcomes, not a global total guessed from a summary. A recovered or ignored outcome can also affect what automation reports, so preserve the truthful operational state. Test boundary cases such as zero failures, exactly the threshold, and one beyond. The offline calculation below states its denominator and comparison explicitly.

python Check an explicitly declared failure-budget boundary

batch_size = 4
threshold = 25
for failed in (0, 1, 2):
    exceeds = (100 * failed / batch_size) > threshold
    print(f'failed={failed} exceeds_threshold={exceeds}')

Expected output

failed=0 exceeds_threshold=False
failed=1 exceeds_threshold=False
failed=2 exceeds_threshold=True

One of four equals 25 percent and does not exceed it; two exceed it. This arithmetic is not an Ansible strategy simulation and triggers no rollout action.

Asynchronous launch is not successful completion

async and poll can change how a long-running task is launched and observed, subject to module and platform support. Fire-and-forget behavior requires later result collection and cleanup; launch acknowledgement alone cannot establish useful completion. Concurrent asynchronous tasks can also bypass the intuitive one-task-at-a-time resource expectation. Decide who owns job identifiers, timeout handling, final status, and cancellation. Check mode and asynchronous support have limitations that must be read for the selected version. Do not use async merely to make a timeout disappear while losing evidence of whether the operation ever finished.

Represent the batch policy without executing a rollout

The illustrative play below uses only a debug description, but still remains non-runnable because no inventory or engine has been exercised. serial and a failure threshold express one part of a plan, not health checking, traffic draining, durable rollback, or capacity validation. A real project should test the sequence and unsupported states on disposable infrastructure before any authorized production procedure. Preserve the previous configuration and define both forward recovery and rollback compatibility. A green final summary does not replace evidence that every returned node is healthy and that skipped or unreachable nodes are understood.

yaml Non-runnable serial and threshold illustration

- name: Illustrate a review-only rolling policy
  hosts: lab_nodes
  gather_facts: false
  serial: 2
  max_fail_percentage: 25
  tasks:
    - name: Describe a planned batch stage
      ansible.builtin.debug:
        msg: Synthetic batch description only

No batch was formed or executed by Ansible. YAML parsing confirms the document structure only; the values are teaching inputs, not universal rollout recommendations.

Common errors and fixes

serial is treated as a complete availability guarantee

Why it happens: Capacity, health, and dependencies were omitted.
How to fix it: Define application gates and remaining-capacity requirements.
Prevent it next time: Test the stated failure scenario before rollout.

A reached percentage is assumed exceeded

Why it happens: The exact threshold comparison was ignored.
How to fix it: Test equality and beyond-threshold cases.
Prevent it next time: Document denominator and scope with the budget.

Async launch is accepted as completion

Why it happens: Job observation and ownership were dropped.
How to fix it: Collect final results and handle timeout/cancellation.
Prevent it next time: Keep asynchronous lifecycle in the public task contract.

Check your understanding

1. With a batch of four and a 25 percent threshold, why should one failure be a separate test from two?

Show worked solution

One reaches the stated percentage while two exceed it. The documented continuation rule distinguishes those cases. Also verify the real engine’s host outcomes and batch context rather than assuming this arithmetic captures rescue, ignored failures, or strategy details.

2. What should be verified before the next batch begins?