run a specific task sequentially for each host

[jack]

Hi, All:

The serial: 1 allows us to run a play sequentially for each host in the host group. But we cannot find similar setting at task level. We want to find a way to run a task in a role sequentially for each host because some external racing issue. Anyone knows how to do it?

Thanks
Jack

[Michael DeHaan]

" We want to find a way to run a task in a role sequentially for each host because some external racing issue. Anyone knows how to do it?"

If this means one host at a time, set up a mini-play with just that task and set "serial: 1" on that play.

--
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 ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Michael DeHaan <mic...@ansibleworks.com>
CTO, AnsibleWorks, Inc.
http://www.ansibleworks.com/

[Serge van Ginderachter]

On 24 January 2014 21:36, Michael DeHaan <mic...@ansibleworks.com> wrote:

If this means one host at a time, set up a mini-play with just that task and set "serial: 1" on that play.

​I too sometimes wished this could be triggered at task level​, so it can be defined at role level.

One of my use cased would then be to use it in a handler (which is just a special task) to avoid race conditions when run on the same delegated host.

Wouldn't this be something?

   Serge

[Michael DeHaan]

So, rather than serial: 1 at a task level (this is a bit of a complex thing), what I really want is the equivalent of the BYPASS_HOST_LOOP code that the pause module uses to be used at a language level also.

Basically thus:

- module_foo: blah

- local_action_once: module blah

- module_baz: blah

I don't think it would make much sense out of a local action.

In the other case, I do believe it should be a seperate play to reuse the existing functionality and make it more explicit.

--
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 ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Serge van Ginderachter]

On 25 January 2014 01:07, Michael DeHaan <mic...@ansibleworks.com> wrote:

I don't think it would make much sense out of a local action.

​I'm not sure. Why?

I see this more in case of delegated tasks. Local is just a delegate to localhost, isn't it?

  Serge​

[Michael DeHaan]

Because it would have to pick a single host arbitrarily.

Shorthand for "only execute on the headnode of a cluster?"

--
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 ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Serge van Ginderachter]

On 25 January 2014 02:05, Michael DeHaan <mic...@ansibleworks.com> wrote:

Because it would have to pick a single host arbitrarily.

Isn't that the same problem of picking which node's hostvars to use when running locally just once?​​

Shorthand for "only execute on the headnode of a cluster?"

Yes, that's basically it I think. Would be a nice feature.

Serge

[jack]

Hi, Michael:

We separated the play, and use serial: 1 for the task which we want to run at one host per time. But we observed that if first node at this task fails, then all the other nodes will not be ran anymore. and also it only reports the failure for the first node, for all other nodes, even though the task is not performed, ansible still reports succeeded.

Something like:

test01                  : ok=12   changed=0    unreachable=0    failed=0
test02                  : ok=14   changed=1    unreachable=0    failed=1


Thanks
Jack