# Are these limitations still deliberate Ansible design choices? **URL:** \ **Category:** Get Help\ **Tags:** windows\ **Created:** [September 5, 2026, 6:55am UTC](https://forum.ansible.com/t/are-these-limitations-still-deliberate-ansible-design-choices/46266 "2026-09-05T06:55:45Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Morgan](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/morgan/32/11122_2.png) [@Morgan](https://forum.ansible.com/u/Morgan)\ **Post date:** [September 5, 2026, 6:55am UTC](https://forum.ansible.com/t/are-these-limitations-still-deliberate-ansible-design-choices/46266/1 "2026-09-05T06:55:45Z")
Hi, I’ve been using Ansible quite a lot for orchestration, and there are a few limitations that I find strange from a design point of view. I’m **not asking for workarounds** here. I know about `include_tasks`, creating multiple plays, `add_host`, etc. What I would like to know is whether these are **still deliberate design choices in current Ansible** , and what the current reasoning is. I did some research before posting, but most explanations I found are quite old. ### 1. Why can’t a `block` be looped? Something like this is not possible: ```yaml - block: - task A - task B loop: "{{ targets }}" ``` The workaround is to move the tasks into another file and loop over `include_tasks`. Brian Coca confirmed that _“blocks do not support any type of loop”_ in this discussion: [Support “until” for blocks](https://forum.ansible.com/t/support-until-for-blocks/20839) But is there a current explanation of **why a block should not be a loopable execution unit**? For orchestration, `for each target -> execute this group of tasks` seems like a natural operation. ### 2. Why can `delegate_to` only target one host? To execute the same task on several delegates, the expected solution is: ```yaml delegate_to: "{{ item }}" loop: - host1 - host2 ``` Brian Coca gives this solution here: [Delegation - Multiple and Parallel](https://forum.ansible.com/t/delegation-multiple-and-parallel/20355) I understand how to do it, but I don’t really understand the design choice. Why shouldn’t `delegate_to` accept a list, group or host pattern? Using the task’s `loop` both for **data iteration** and **execution target iteration** also becomes awkward when both are needed. ### 3. Why can’t a task define/change its host scope? Brian Coca answered this very clearly in: [Change hosts variable when including another playbook](https://forum.ansible.com/t/change-hosts-variable-when-including-another-playbook/22634) > “you don’t, you create a new play that targets those hosts” I also found Michael DeHaan’s original explanation around the introduction of `delegate_to`: [New delegate\_to feature](https://forum.ansible.com/t/new-delegate-to-feature-for-orchestrating-outage-windows-and-talking-with-load-balancers-etc/11808) So I understand the Ansible model is basically: ```plaintext Play -> hosts -> tasks ``` and not: ```plaintext Task -> hosts ``` But is this still considered the right abstraction today, especially for dynamic orchestration where the target machines can change several times during a workflow? * * * Ansible documentation explicitly describes playbooks as providing configuration, deployment and orchestration functions, including orchestration across multiple sets of machines For orchestration, operations such as: ```plaintext remove a server from a load balancer -> perform several maintenance tasks on that server -> validate it from a monitoring host -> add it back to the load balancer -> repeat for the remaining servers ``` are quite natural. Ansible can do all of this, but sometimes the YAML structure becomes much more complicated than the actual orchestration logic because of the Play/Task/Block boundaries. So my main questions are: 1. Are these restrictions still deliberate design choices in current `ansible-core`? 2. What is the current architectural reasoning behind them? 3. Are they required by the execution/strategy model, or mainly historical limitations? 4. Have these choices been reconsidered since those older discussions? I’m mainly interested in understanding the design rationale, rather than finding another workaround. ---
**Author:** ![kks](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/kks/32/10352_2.png) [@kks](https://forum.ansible.com/u/kks)\ **Post date:** [September 5, 2026, 7:41am UTC](https://forum.ansible.com/t/are-these-limitations-still-deliberate-ansible-design-choices/46266/2 "2026-09-05T07:41:21Z")
These are very good questions, indeed. I am also interested. ---
**Author:** ![bcoca](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/bcoca/32/9269_2.png) [@bcoca](https://forum.ansible.com/u/bcoca)\ **Post date:** [September 5, 2026, 1:01pm UTC](https://forum.ansible.com/t/are-these-limitations-still-deliberate-ansible-design-choices/46266/3 "2026-09-05T13:01:35Z")
I know these won’t be satisfying, but just trying to give some short answers to the main questions. > 1. Are these restrictions still deliberate design choices in current `ansible-core`? yes > 1. What is the current architectural reasoning behind them? The reasoning has not changed and not likely to w/o first a major revamp of the engine > 1. Are they required by the execution/strategy model, or mainly historical limitations? yes and yes > 1. Have these choices been reconsidered since those older discussions? yes, we do revisit long standing questions every so often, but nothing has changed, see #2 ---
**Author:** ![system](https://us1.discourse-cdn.com/ansible/original/1X/1882d9a01da5d8996a862359b0913cc568a39b84.svg) [@system](https://forum.ansible.com/u/system)\ **Post date:** [October 5, 2026, 1:02pm UTC](https://forum.ansible.com/t/are-these-limitations-still-deliberate-ansible-design-choices/46266/4 "2026-10-05T13:02:20Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.