CODEWITHSUNDEEP
ansibleansible-facts
timothepoznanski
timothepoznanski

Reputation: 1112

Why should I remove the "ansible_" prefix when refering to an ansible fact?

I get these facts when running the setup module :

# ansible localhost -m setup | more
localhost | SUCCESS => {
    "ansible_facts": {
        "ansible_default_ipv4": {
            "address": "51.XX.XX.XX",
            "alias": "eth0",  
            [...]

If I want to get the ip address and use it my play, here is what works:

{{ ansible_facts.default_ipv4.adress }}

However, I don't understand why we don't do:

{{ ansible_facts.ansible_default_ipv4.adress }}

Why "ansible_" should be removed?

Maybe I missed something or maybe it is just a rule or a convention but it doesn't seem to me logical.

Upvotes: 2

Views: 720

Answers (2)

U880D
U880D

Reputation: 12121

... maybe it is just a rule or a convention ...

It is an option.

According documentation Ansible facts

You can access this data in the ansible_facts variable. By default, you can also access some Ansible facts as top-level variables with the ansible_ prefix.

The behavior is configurable via INJECT_FACTS_AS_VARS

Facts are available inside the ansible_facts variable, this setting also pushes them as their own vars in the main namespace.

Further Q&A

Upvotes: 2

timothepoznanski
timothepoznanski

Reputation: 1112

@U880D answer is good and pointed me to the right direction thanks. However I needed more informations to understand exactly what is happening and why. After digging into the official RedHat course (RH294), I found my answer here:

Before Ansible 2.5, facts were injected as individual variables prefixed with the string ansible_ instead of being part of the ansible_facts variable. For example, the ansible_facts['distribution'] fact would have been called ansible_distribution.

Many older playbooks still use facts injected as variables instead of the new syntax that is namespaced under the ansible_facts variable. You can use an ad hoc command to run the setup module to print the value of all facts in this form.

After testing, their is actualy a difference between the result when using the setup ad hoc command and the setup as a module in a playbook!

The ad hoc command displays the variables the old way:

# ansible localhost -m setup | more
localhost | SUCCESS => {
    "ansible_facts": {
        "ansible_all_ipv4_addresses": [
            "51.XX.XX.XX",
            "10.XX.XX.XX"
        ],

Note the "ansible_" prefix in the above example.

Now, running setup from a playbook gives a different result:

# ansible-playbook plabook.yml

TASK [Task] ******************************************************************************************************************************************************************
ok: [localhost] => {
    "ansible_facts": {
        "all_ipv4_addresses": [
            "51.75.251.107",
            "10.88.0.1"
        ],

The prefix "ansible_" has disapeared!

My problem came from the result of the ad hoc command that was "misleading" me.

But this won't last. Here is what the Red Hat from the course documentation says:

Currently, Ansible recognizes both the new fact naming system (using ansible_facts) and the old pre-2.5 "facts injected as separate variables" naming system.

You can turn off the old naming system by setting the inject_facts_as_vars parameter in the [default] section of the Ansible configuration file to false. The default setting is currently true.

The default value of inject_facts_as_vars will probably change to false in a future version of Ansible. If it is set to false, you can only reference Ansible facts using the new ansible_facts.* naming system.

Upvotes: 3

Related Questions