Ansible Facts - Management

[Trevor]

An ansible_facts variable is responsible for storing Ansible facts.

What manages an ansible_facts variable?

[Chetan_Tiwary_ · Accepted solution]

@Trevor 

The ansible_facts variable is a powerful feature that Ansible manages automatically using its setup module. 

ansible <hostname> -m ansible.builtin.setup

When a playbook begins, Ansible's first step is to run the setup module on every single host it's targeting. This happens automatically unless you explicitly disable it. 

All of this collected information is then stored in the ansible_facts variable. Once it's populated, you can use it throughout your playbook to make smart, dynamic decisions. 

If you ever set gather_facts: no in your playbook, that initial collection step is skipped. As a result, the ansible_facts variable will be mostly empty, and any tasks that rely on it won't work correctly. However, you can always call the setup module manually in a task to get the facts if you need them later on in your play.

https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_vars_facts.html 

[Trevor]

Chetan, thanks for another elevating response!

The answer that you provided to my query is that Ansible manages the
ansible_facts variable.  The answer that I was fishing for was Ansible Engine!

Am I being too nitpicky?  

Surely, with Ansible Engine being obsolete, the response that I should really be
after Red Hat Ansble Automation Platform.

I still get a little dizzy when I see the use of "Ansible" all by itself.  I stil feel its
a little reckless to use that term alone, when it refers to a framework, as well 
as tools.  Anyway, it's my hangup, and I'll just have to continue with my therapy
to get over it

[Chetan_Tiwary_]

@Trevor  Trevor, your point is totally valid.  I should have been more precise. Technically, the ansible_facts gathering is performed by the Ansible Engine / ansible-core component (or historically, the “Engine” product). Saying “Ansible” generically obscures which layer or product we’re talking about. Thanks for pushing me to be more exact. I will be careful!

[Travis]

I would argue somewhat against that because we still have the ansible command which was once known as Ansible Engine but now bundled and packaged as ansible-core. If you take it even further, most system facts come from the ansible.builtin.setup module for fact gathering, but there are many other modules that can create, generate, and collect Ansible facts, but some of those are migrating to ".info" modules.

Red Hat Ansible Automation Platform is the product and entire suite which covers controller, private automation hub, EDA controller, the components for Ansible Automation Mesh, and now the newer gateway components as of AAP 2.5.

The plain old ansible command does collect, manage, and use facts without the need for AAP because you are using the setup module to return those facts. Can you do much with a single ad-hoc command no, but that doesn't mean it doesn't collect and gather facts. Typically, you need a playbook that leverages a play with multiple tasks to gather facts and use those facts for additional tasks in the playbook.

What does Ansible Automation Platform give you, well, Automation Controller and web interface and a database to store those facts in to be used with the inventory and playbooks (Job Templates/Workflows) without needing to recollect the facts because those are housed and available.

Facts however can be stored locally on a controlled node without the use of the entire AAP platform and can be leveraged with playbooks and other ad-hoc commands using just the ansible command or ansible-playbook command which ships as part of ansible-core package.

Addtionally, Red Hat releases the rhel-system-roles package as an RPM specifically as part of the RHEL distribution to assist with automation and management of systems providing the collections and all pieces needed to manage a RHEL system without requiring an AAP subscription and the use of execution environments and installing collections from multiple sources.

RHEL10 Ansible Setup (non-AAP)

https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/automating_system_administ...

RHEL System ROLES : https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/automating_system_administ...

https://access.redhat.com/articles/3050101 

[Travis]

@Trevor -

Another point is technically ansible_facts aren't really variables. Those are "facts" that are discovered. Granted, you can create custom facts on systems that can be read and set with the setup module, but again, these are things that are discovered by Ansible modules. Variables are changing values that can be specified and set and allow automation to be performed on multiple systems. 

It is also possible to use the set_fact to leverage playooks and output from tasks to set new facts.

Ansible Facts	Ansible Variables
Automatically discovered from managed nodes.	Manually defined by the user.
Dynamic and reflect the current state of the system.	Static until explicitly changed by the user.
Cannot be directly modified by the user.	Can be easily modified and redefined.
To make playbooks aware of the target environment.	To make playbooks flexible, reusable, and configurable.