Delgate_facts understanding

[Vicente Domínguez]

Hello everyone,

I don't totally get the point of the delegate_facts usage in Ansible.

I have written the follow code to test this clause:

- name: delegate facts testing

  hosts: localhost

  tasks:

  

   - name: print FQDN - first attempt

     debug:

      msg: "{{ ansible_fqdn }}"

  - name: gather facts on remote host

    setup:

    delegate_to: "{{ item }}"

    with_items: "{{ groups['anotherhost'] }}"

    delegate_facts: false

   

  - name: print ansible FQDN - second attempt

    debug:

     msg: "{{ ansible_fqdn }}"

So... If I set DELEGATE_FACTS to false, I get the following output:

     --> PRINT FQDN - First attempt   --> LOCAL HOSTNAME

     --> PRINT FQDFN - Second attempt --> ANOTHER HOSTNAME

• Is this because the default facts gathered at the beginning of the play (via setup localhost) , have been overwritten by the facts gathered on the ANOTHERHOST?

Otherwise, If I change delegate_facts to true. I obtain LOCALHOSTNAME in both attempts.

•  Is this because I ve assigned the default gathered facts to anotherhost's facts?

    

Sorry for this silly question.. but I cannot find an example good enough to understand this.

Thank you all in advance :)

Vicente.

[Vladimir Botka]

On Sat, 2 Nov 2019 14:57:50 -0700 (PDT)
Vicente Domínguez <vi1...@gmail.com> wrote:

> *- name: delegate facts testing*
> * hosts: localhost
> * tasks:
> * - name: print FQDN - first attempt
> * debug:
> * msg: "{{ ansible_fqdn }}"
> * - name: gather facts on remote host
> * setup:
> * delegate_to: "{{ item }}"
> * with_items: "{{ groups['anotherhost'] }}"
> * delegate_facts: false
> * - name: print ansible FQDN - second attempt
> * debug:
> * msg: "{{ ansible_fqdn }}"

>
> If I set DELEGATE_FACTS to false, I get the following output:
> --> PRINT FQDN - First attempt --> LOCAL HOSTNAME
> --> PRINT FQDFN - Second attempt --> ANOTHER HOSTNAME
>
> Is this because the default facts gathered at the beginning of the
> play (via setup localhost) , have been overwritten by the facts gathered on
> the ANOTHERHOST?

YES.

> Otherwise, If I change delegate_facts to true. I obtain LOCALHOSTNAME in
> both attempts.
>
> Is this because I ve assigned the default gathered facts to
> anotherhost's facts?

YES.


For the reference: "The directive delegate_facts may be set to True to assign
the task’s gathered facts to the delegated host instead of the current one."
https://docs.ansible.com/ansible/latest/user_guide/playbooks_delegation.html#delegated-facts

Cheers,

-vlado

[Vicente Domínguez]

Thank you very much Vlado.

But it means that you have to manage this clause carefully, because if you use delegate_facts = FALSE  (true by default) , the rest of your tasks after the delegated one will be using {{ ansible_fqdn }} with a wrong hostname (different from the current managed host), which could lead to errors... =S

I don't get the point of this functionality at all, any useful example that you have in mind?

Thank you for your help :)

[Vladimir Botka]

On Sun, 3 Nov 2019 12:27:15 -0800 (PST)
Vicente Domínguez <vi1...@gmail.com> wrote:

> But it means that you have to manage this clause carefully, because if you
> use delegate_facts = FALSE (true by default) , the rest of your tasks
> after the delegated one will be using {{ ansible_fqdn }} with a wrong
> hostname (different from the current managed host), which could lead to
> errors... =S

YES. (... if you use "delegate_facts: false" (false by default) ...)

To avoid the problem use "delegate_facts: true" with the "setup" module.

> I don't get the point of this functionality at all, any useful example that
> you have in mind?

The example in the doc is a good use-case
https://docs.ansible.com/ansible/latest/user_guide/playbooks_delegation.html#delegated-facts

- hosts: app_servers
tasks:
- name: gather facts from db servers
setup:
delegate_to: "{{item}}"
delegate_facts: True
loop: "{{groups['dbservers']}}"

The play is running at app_servers and knows nothing about the dbservers.
The task will "setup" dbservers facts that can be used by app_servers.

Cheers,

-vlado

[Vicente Domínguez]

Hello,

Are we sure that the delegate_facts is set to "false" by default? As stated in the doc:

"By default, any fact gathered by a delegated task are assigned to the inventory_hostname (the current host) instead of the host which actually produced the facts (the delegated to host)"

If the facts gathered by a delegated task are assigned to inventory_hostame (CURRENT HOST), means that the delegate_facts = true, isn't it?

As per my first code example, if you use delegate_facts = false, you will have the delegated hosts's facts instead of inventory_hostnames's (which are overridden). In the case of delegate_facts = true, you will keep CURRENT inventory_hostname's facts along the whole play.

Thank you very much, sorry for bothering with this :)

By the way, your example makes sense..  if you want to use DB Servers facts in APPServers tasks.

Thanks a lot,

Vicente.

[Vladimir Botka]

On Sun, 3 Nov 2019 23:26:19 -0800 (PST)
Vicente Domínguez <vi1...@gmail.com> wrote:

> Are we sure that the delegate_facts is set to "false" by default?

(I wonder how "we" can be sure? Kind of a collective experience?)

The default can be easily tested. For example the play

- hosts: test_01
tasks:
- setup:
delegate_to: test_02
delegate_facts: true
- debug:
var: ansible_hostname

gives

ok: [test_01] => {
"ansible_hostname": "test_01"
}

The same play without the line "delegate_facts: true" gives

ok: [test_01] => {
"ansible_hostname": "test_02"

}


> By the way, your example makes sense.. if you want to use DB Servers facts
> in APPServers tasks.

It's not my example. It's been publicly available for a while.

[Vicente Domínguez]

Great! 

So I can say that the wording of the doc is not totally accurate...

MENTAL NOTE: If it's false by default, just take care and don't forget to use delegate_facts = true (setup module) if you don't want to override the facts.

Regarding "your example" I meant that It was suggested by you to check :)

Thank you very much Vlado, hope it helps for my certification exam this week!

Cheers.

[Vladimir Botka]

On Mon, 4 Nov 2019 00:46:03 -0800 (PST)
Vicente Domínguez <vi1...@gmail.com> wrote:

> So I can say that the wording of the doc is not totally accurate...

No. The wording is OK.
https://docs.ansible.com/ansible/latest/user_guide/playbooks_delegation.html#delegated-facts

Short story
===========
Read "delegate_facts: true" as "In the task, which is delegated to hostX,
use the facts of hostX as well".

Details
=======

Statement: "By default, (1) any fact gathered by a delegated task (2) are
assigned to the inventory_hostname (the current host) (3) instead of the
host which actually produced the facts (the delegated to host). (4) The

directive delegate_facts may be set to True to assign the task’s gathered
facts to the delegated host instead of the current one."

Example

- hosts: test_01
tasks:
- setup:
delegate_to: test_02
delegate_facts: true
- debug:
var: ansible_hostname

1) "any fact gathered by a delegated task" - Is the setup facts of test_02
in my example

"ansible_hostname": "test_02"

2) "are assigned to the inventory_hostname (the current host)" - Which is
test_01 in my example

3) "instead of the host which actually produced the facts (the delegated to
host)" - which is test_02 in my example


This has been confirmed. The play without the line "delegate_facts:

true" gives

ok: [test_01] => {
"ansible_hostname": "test_02"
}

4) "The directive delegate_facts may be set to True to assign the task’s
gathered facts to the delegated host" - which is test_02 in my example

This has been confirmed. The variable "ansible_hostname" of test_01 was
not replaced with "test_02". The play gives

ok: [test_01] => {
"ansible_hostname": "test_01"
}

* Opposite to "delegate_facts: true" is "delegate_facts: false"

> Regarding "your example" I meant that It was suggested by you to check :)
> Thank you very much Vlado, hope it helps for my certification exam this
> week!

(Please. Put me at least into CC when you address me in the text.)

You're welcome. Good luck!

-vlado

[Vicente Domínguez]

I understand this the other way around:

  Short story
  ===========
  Read "delegate_facts: true" as "In the task, which is delegated to hostX,
  use the facts of hostX as well".

delegate_facts: true:

If you are in HOST Y (test_01) and you delegate a task to HOST X (Test_02), HOST X will inherit HOST Y facts instead of overridding them with HOST's X in their way back.

That's why you will print  "ansible_hostname": "test_01"  instead of "test_02"

delegate_facts: false

Host X delegated task will gather facts and HOST Y (current) facts will be overridden. That's why you will print  "ansible_hostname": "test_02"  instead of "test_01"

I truly don't know what I'm missing!

[Drew Northup]

Ok,

There's several things going on here:
(1) The wording in the doc isn't great and it isn't grammatically "correct" either, so it is not "OK";

(2) The wording in the doc is accurate relative the originally intended function of the "delegate_facts" switch;

(3) The metaphor "delegate_facts" isn't very helpful in understanding what is actually going on—as facts aren't what is being delegated, but it is in fact the custody of them that is.

Item #3 on my list is clearly (to a native speaker / writer of English) indicated in the paragraph following the example code on the documentation page. Setting the "delegate_facts" switch to true means that not only are the shorthand host vars (EG: "ansible_hostname") of the original target host PRESERVED in the environment running on the delegate target host, but it also means that facts gathered on the delegate host end up IN THE CUSTODY OF the original target host (or host group) that will be running the play. This is done without overriding the shorthand host vars, as to do so would, within the constraining metaphor of Ansible, be without any intended meaning.

Vincente,

Does that explanation help?

Vlado,

Do you want to proof a quick fix to the grammar & wording of the doc page (before or after I post a PR)?

[Vladimir Botka]

On Mon, 4 Nov 2019 07:37:22 -0800 (PST)
Drew Northup <drew.n...@maine.edu> wrote:

> Vlado,
> Do you want to proof a quick fix to the grammar & wording of the doc page
> (before or after I post a PR)?

Sure. Post it here. Others might be interested too.

Thank you,

-vlado

[Vicente Domínguez]

Thank you both! Eveything clear now :)

By the way, what does "PR" mean?

[Vladimir Botka]

On Mon, 4 Nov 2019 23:51:57 -0800 (PST)
Vicente Domínguez <vi1...@gmail.com> wrote:

> By the way, what does "PR" mean?

> > Do you want to proof a quick fix to the grammar & wording of the doc page
> > (before or after I post a PR)?

It is "Pull Request".
https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests

No PR by Benjamin yet
https://github.com/ansible/ansible/pulls

Cheers,

-vlado

[Vladimir Botka]

On Mon, 4 Nov 2019 23:51:57 -0800 (PST)
Vicente Domínguez <vi1...@gmail.com> wrote:

> By the way, what does "PR" mean?

> > Do you want to proof a quick fix to the grammar & wording of the doc page
> > (before or after I post a PR)?

It is "Pull Request".
https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests

No PR by Drew yet
https://github.com/ansible/ansible/pulls

Cheers,

-vlado