(For others reading the list, I replied to the other copy of this post)
On Thu, Jan 23, 2014 at 6:47 PM, Mike Sop <[email protected]> wrote: > 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. > -- Michael DeHaan <[email protected]> CTO, AnsibleWorks, Inc. http://www.ansibleworks.com/ -- 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.
