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 On Saturday, August 18, 2012 6:24:42 AM UTC-7, Michael DeHaan wrote: > > 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 > > > On Saturday, August 18, 2012 8:59:59 AM UTC-4, Michael DeHaan wrote: >> >> 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. >> 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: >> >> --- >> - hosts: foo >> >> tasks: >> >> - name: on actual host >> action: command echo hi mom ($inventory_hostname) >> >> - name: delegated >> action: command echo hi mom ($inventory_hostname) >> delegate_to: 127.0.0.1 >> >> >> What will happen is the first step will run just like normal, executed >> on all hosts in the group "foo". >> >> The second task, however, will run one time for each host on group >> "foo", but every single command will run on 127.0.0.1 with reference >> to the variables normally available to the other hosts. >> >> A more real world example, illustrating the usage of two different >> connection types, would be: >> >> >> --- >> - hosts: foo >> connection:local >> >> tasks: >> >> - name: start outage window >> action: /usr/bin/start_outage_window $inventory_hostname 20m >> delegate_to: 127.0.0.1 >> >> - hosts: foo >> >> - name: do something important >> action: service name=blarg state=stopped >> >> # other stuff here >> >> >> So, I hope that gives the general idea of what delegate_to is capable >> of. It's really open-ended, so you could technically integrate it >> with a power management script, pizza ordering, pretty much anything. >> >> I think the next step here that would be really really interesting is >> if we start seeing modules written (and hopefully added to core) for >> talking with various monitoring servers and load balancers. I've >> already talked with a few people of getting some of the nagios >> interaction from Func/Taboot ported over, but I think there's room for >> a lot more -- so if you have any ideas for modules that could take a >> lot of advantage of this, let me know! >> > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
