You mean the tasks should run in the first node available? If host1 is
unavailable the tasks should run in the host2, but if host2 is also
unavailable should run in host3 and so on?
I think is a valid concern. Even delegate_to could be set to a host
which may be is unavailable. The idea here is the tasks must run,
don't care which host, but must run anyway. May be an option?
On Mon, Mar 19, 2018 at 6:18 PM, Alex Hunt <al...@exabeam.com> wrote:
> The issue has nothing to do with delegate_to. The issue has to do with
> whether it decides to run at all, which delegate_to has no effect on. I
> don't care which host it runs on, and if I did, I could use delegate_to as
> you have noted. The delegate_to directive works properly.
>
> It is totally fine for it to execute on the first host in the inventory, as
> long as it runs when that host is skipped for the included task book. I
> apologize if I'm not being clear about what the issue is.
>
> Here's the same example, updated with a delegate_to, since everyone seems to
> think that matters.
>
> Inventory
> [all]
> host1
> host2
> host3
>
> Playbook
> - name: Test Play
> hosts: all
> tasks:
> - include: outer-task.yml
>
> outer-task.yml
> - name: Outer task
> include: inner-task.yml
> when: inventory_hostname != 'host1'
>
> inner-task.yml
> - name: Inner task
> command: do_something
> run_once: True
> delegate_to: 'host2'
>
> In this example, it should run on host2, but it does not, since host1 skips
> the entire inner-task.yml. This is the problem.
>
> In my original example, I didn't care if it ran on host1, as long as it ran,
> but it doesn't run at all.
>
> On Monday, March 19, 2018 at 1:54:06 PM UTC-7, Matt Martz wrote:
>>
>> The behavior is documented via that information provided above. `run_once`
>> in it's current form is designed to be consistent and predictable in which
>> host is picked to execute the task against.
>>
>> > When “run_once” is not used with “delegate_to” it will execute on the
>> > first host, as defined by inventory, in the group(s) of hosts targeted by
>> > the play
>>
>> If the first host is failed, it is removed from the play list, and
>> run_once will therefore be skipped.
>>
>> Using `delegate_to` allows you to define what you believe is consistent or
>> predictable. If you don't care what host it executes on, using `delegate_to`
>> can be made to do what you want:
>>
>> - command: whoami
>> run_once: true
>> delegate_to: "{{ ansible_play_hosts|first }}"
>>
>> `ansible_play_hosts` is updated as hosts fail.
>>
>> So if it started as:
>>
>> "ansible_play_hosts": [
>> "host0",
>> "host1",
>> "host2",
>> "host3",
>> "host4"
>> ]
>>
>> and `host0` failed, that `delegate_to` above will utilize `host1`.
>> Instead of first, something like `random` could be used too.
>>
>> If you wish to add further, constructive, clarification to the docs, and
>> potentially examples such as the one I provide above, feel free to submit a
>> documentation pull request.
>>
>> On Mon, Mar 19, 2018 at 3:33 PM, Alex Hunt <al...@exabeam.com> wrote:
>>>
>>> I think you're confused by what the issue is. Whether I use delegate_to
>>> or not is irrelevant. I don't care which host it runs on, and if I did, I
>>> would use the delegate_to. Even if I use delegate_to, it will still be
>>> skipped, since it evaluates whether to run the task at all based on the
>>> first host. I'm sorry I didn't include a delegate_to in my example, which
>>> lead to this confusion.
>>>
>>> http://docs.ansible.com/ansible/latest/playbooks_delegation.html#run-once
>>> makes no mention of the fact that even with delegate_to it decides whether
>>> to run at all based on the first host. The mention of delegate_to actually
>>> makes this more confusing, since that The delegate_to should control where
>>> the execution happens (something irrelevant to this issue), not whether it
>>> runs at all. That part is at least consistent, since delegate_to does not
>>> control whether to run it.
>>>
>>> The issue is that run_once is not actually running once. It is "run only
>>> if the first node in the play says to run it", not "run one time if it
>>> should run for any host in the play". The latter is intuitive behavior. You
>>> talk of predictable results, and it is not predictable to have behavior that
>>> changes based on the order of hosts in your inventory file (the current
>>> behavior).
>>>
>>> Please note that in my example, the when clause is NOT on the task with
>>> run_once. If we make reusable code, we may be including that piece in many
>>> places, with or without the when clause.
>>>
>>>
>>> On Monday, March 19, 2018 at 12:15:13 PM UTC-7, flowerysong wrote:
>>>>
>>>> On Monday, March 19, 2018 at 2:49:12 PM UTC-4, Alex Hunt wrote:
>>>>>
>>>>> When running a task with run_once, if the first node is skipped, the
>>>>> entire task is skipped, rather than running on the first host that is not
>>>>> skipped.
>>>>>
>>>>> This behavior is not what is intuitively understood, this behavior is
>>>>> not mentioned in the docs, and this behavior is almost certainly not what
>>>>> most of people want it to do. There are discussions of this in multiple
>>>>> github issues, the most detailed of which is at
>>>>> https://github.com/ansible/ansible/issues/19966, but there are also at
>>>>> least
>>>>> https://github.com/ansible/ansible/issues/11496,
>>>>> https://github.com/ansible/ansible/issues/13226, and
>>>>> https://github.com/ansible/ansible/issues/23594.
>>>>
>>>>
>>>> It may confuse some people, but it's both the documented behaviour and
>>>> the least surprising way to do things. Conditionals should not affect the
>>>> number of times a run_once task is evaluated even if they result in the
>>>> task
>>>> being skipped.
>>>>
>>>>
>>>> https://docs.ansible.com/ansible/latest/playbooks_delegation.html#run-once
>>>> says: "When “run_once” is not used with “delegate_to” it will execute on
>>>> the
>>>> first host, as defined by inventory, in the group(s) of hosts targeted by
>>>> the play - e.g. webservers[0] if the play targeted “hosts: webservers”."
>>>>
>>>>>
>>>>> Below is an untested simple example of a scenario that would skip the
>>>>> run_once task, when it should (according to the docs, and common sense)
>>>>> run
>>>>> on one of either host2 or host3.
>>>>>
>>>>> Inventory
>>>>> [all]
>>>>> host1
>>>>> host2
>>>>> host3
>>>>>
>>>>> Playbook
>>>>> - name: Test Play
>>>>> hosts: all
>>>>> tasks:
>>>>> - include: outer-task.yml
>>>>>
>>>>> outer-task.yml
>>>>> - name: Outer task
>>>>> include: inner-task.yml
>>>>> when: inventory_hostname != 'host1'
>>>>>
>>>>> inner-task.yml
>>>>> - name: Inner task
>>>>> command: do_something
>>>>> run_once: True
>>>>>
>>>>> This issue is exacerbated by the fact that the inner task may have no
>>>>> idea why the first host is skipped (IE: we're including a reusable task
>>>>> that
>>>>> may get run many times in different ways). In those cases, there is no way
>>>>> to work around the issue with a simple `when: inventory_hostname ==
>>>>> something`, since we don't know what to check against.
>>>>
>>>>
>>>> You're mixing different ways of limiting where a task runs, with
>>>> predictable results (the task is assigned to one host, and the conditional
>>>> results in it being skipped). If you don't care which host it runs on, use
>>>> run_once without a conditional. If you want to run it on a specific host,
>>>> use delegate_to with run_once or a conditional without run_once.
>>>
>>> --
>>> 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.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/ansible-project/1b542a8f-8f75-462a-8c11-0fd0c76054dc%40googlegroups.com.
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>>
>> --
>> Matt Martz
>> @sivel
>> sivel.net
>
> --
> 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-project+unsubscr...@googlegroups.com.
> To post to this group, send email to ansible-project@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/38cf4ed5-6285-464a-a81a-68a44d04709a%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
Marcos H. Alano
Linux System Administrator
marcoshal...@gmail.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 ansible-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/CAO3Us%3D%3D%3DLzqtZDdSgvyoO1YGdBJ2TRcYN0%2BqF7P9jbfg_sJTbA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
