# New 'delegate\_to' feature -- for orchestrating outage windows and talking with load balancers, etc

**URL:** <https://forum.ansible.com/t/new-delegate-to-feature-for-orchestrating-outage-windows-and-talking-with-load-balancers-etc/11808>\
**Category:** Ansible Project\
**Tags:** windows\
**Created:** [August 18, 2012, 12:59pm UTC](https://forum.ansible.com/t/new-delegate-to-feature-for-orchestrating-outage-windows-and-talking-with-load-balancers-etc/11808 "2012-08-18T12:59:59Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [August 18, 2012, 12:59pm UTC](https://forum.ansible.com/t/new-delegate-to-feature-for-orchestrating-outage-windows-and-talking-with-load-balancers-etc/11808/1 "2012-08-18T12:59:59Z")

</div>

When I first started ansible, one of the things I wanted it to be  
exceptionally good at is multi-machine rollouts, where there are  
various tiers of application architecture. This is why you can do  
different hosts in different plays and why it is push based -- so you  
have really fine grained control about what machines you talk to when.  
&nbsp;&nbsp;One of the things that doesn't quite fall into this model though is  
when you have to talk to monitoring servers or load balancers. Until  
today.

Generally speaking, the new option on a task 'delegate\_to', allows a  
command to be run on a specified address with reference to the address  
of each host selected in the play. This is one of the last missing  
pieces missing to orchestrate some pretty impressive steps.

Here's a super trivial example:

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [August 18, 2012, 1:24pm UTC](https://forum.ansible.com/t/new-delegate-to-feature-for-orchestrating-outage-windows-and-talking-with-load-balancers-etc/11808/2 "2012-08-18T13:24:42Z")

</div>

The follow up to this feature, by the way, is going to be the ability to mark a playbook as “serial: True”, which means it will entirely complete a play  
on a single host, before moving on to the next set.

This will probably respect the --forks flag for how many to do at once.

I’ve filed a ticket for this idea here: [https://github.com/ansible/ansible/issues/904](https://github.com/ansible/ansible/issues/904)

---

<div class="post-metadata">

**Author:** ![Mike\_Sop](https://avatars.discourse-cdn.com/v4/letter/m/4af34b/32.png) [@Mike\_Sop](https://forum.ansible.com/u/Mike_Sop)\
**Post date:** [January 23, 2014, 11:47pm UTC](https://forum.ansible.com/t/new-delegate-to-feature-for-orchestrating-outage-windows-and-talking-with-load-balancers-etc/11808/3 "2014-01-23T23:47:28Z")

</div>

Is there a way to mark a particular task as “serial”? The ticket below appears to be resolved but by its description looks like this can set a “playbook” as serial (the entire playbook instead of just a particular task? In which case should I create a different playbook for this task (is that the intended workflow) or maybe that fix isn’t in the version I’m on (1.3.4) getting this error when I try to add serial to a task:

ERROR: serial is not a legal parameter in an Ansible task or handler

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\
**Post date:** [January 24, 2014, 1:06am UTC](https://forum.ansible.com/t/new-delegate-to-feature-for-orchestrating-outage-windows-and-talking-with-load-balancers-etc/11808/4 "2014-01-24T01:06:56Z")

</div>

(For others reading the list, I replied to the other copy of this post)