gistfile1.txt

Ansible execution begins with the script: `bin/ansible`. This script is sym-linked to other names, such as ansible-playbook and ansible-pull, ansible-conneciton being the exception.

When executed, this script looks at the first parameter passed to it. On Linux/Unix systems, this parameter is the name of the script itself. By examining this value, we can determine which CLI class we should load and execute.

Ansible CLI Classes:
- AdHocCLI (the plain "ansible" command)
- PlaybookCLI (when run with "ansible-playbook")
- PullCLI (when run with "ansible-pull")
- DocCLI (when run with "ansible-doc")
- GalaxyCLI (when run with "ansible-galaxy")
- VaultCLI (when run with "ansible-vault")
- ConsoleCLI (when run with "ansible-console")

Each of these CLI classes is a sub-class of the CLI class found in `lib/ansible/cli/__init__.py`. This base class defines some common methods to all CLI classes, such as option parsing and loading the Ansible configuration file.

The entry point for the CLI classes is the `run()` method, which takes no arguments. In this document, we will cover how the PlaybookCLI class works. In many ways, the AdHocCLI and PullCLI classes function in a similar way to the PlaybookCLI class, however the other classes are very different and will not be covered here.

How Ansible Works
#################

When `run()` is called from the PlaybookCLI class, Ansible creates several objects which are singletons across the life of the run:

1. DataLoader() (`lib/ansible/parsing/dataloader.py`)
2. VariableManager() (`lib/ansible/vars/__init__.py`)
3. Inventory ('lib/ansible/inventory/__init__.py`)
4. PlaybookExecutor ('lib/ansible/executor/playbook_executor.py`)

after inv_plugins:
2. VariableManager() (`lib/ansible/vars/manager.py`)
3. Inventory ('lib/ansible/inventory/{data,manager}.py`)

VariableManager
---------------

The VariableManager codifies the variable precedence rules for Ansible. It allows Ansible to generate a "view" of variables, based on a set of given objects: the current play, the current host, and the current task. Any one of these may be omitted. Usually, vars are fetched with the following combinations of objects:

- (play,) (early on during playbook parsing time)
- (play, host) (some inventory specific parsing functions)
- (play, host, task) (task validation and execution)

# before inv_plugins
The VariableManager also manages loading vars files for play host and group vars, roles (`defaults/main.yml` and `vars/main.yml`), and the vars_files specified in any plays.

# after inv_plugins
The VariableManager also manages vars_plugins for things like loading host_vars/ and group_vars/ files, roles (`defaults/main.yml` and `vars/main.yml`), and the vars_files specified in any plays.

Finally, the VariableManager generates and retrieves what we call "magic" variables, which are internal representations of Ansible state or other variables which cannot be defined anywhere else.