Inventory sources

While the functionality of each integration will remain the same regardless of how the inventory device is sourced (internal or external), it is important to understand how Itential Automation Gateway (IAG) will behave in each scenario.

Internal inventory

An Internal inventory source simply means that an External file path was not supplied, or not correctly loaded; therefore, you must manage your inventory exclusively through the GUI or APIs.

Pros	Cons
Inventory can be fully managed via API calls for end-to-end automations that do not have access to the underlying file system.	Certain inventory features of an integration must be adapted to fit inside of a JSON structure instead of other file formats supported by that integration (e.g., YAML for Ansible, etc.).

External inventory

An External inventory source indicates that you have provided the correct file path to the relevant inventory or configuration file for your integration. Because the external file serves as the source of truth, IAG cannot directly modify it, and the Internal inventory option is disabled. To update an External inventory, you must edit the file directly and then prompt IAG to refresh its inventory data.

Pros	Cons
All native inventory options are available for each integration (for example, complex `ini` groups and variables with Ansible)	The underlying file system must be kept up-to-date through file syncing protocols, scripts, cron jobs, or manual processes

Refresh external inventories

After modifying an external inventory file, refresh the inventory in IAG using one of the following methods:

Refresh endpoint

Refresh the inventory by calling the refresh endpoint: POST /inventory/refresh.

Example request URL: http://<iag-hostname>:8083/api/v2.0/inventory/refresh

Replace <iag-hostname> with your IAG hostname or IP address.

Example response:

1 {
2   "code": 200,
3   "message": "Inventory refresh succeeded"
4 }

For more information, see Viewing endpoints and methods.

Refresh from UI

Refresh the inventory from the IAG UI by selecting the Devices refresh icon.

Ansible and inventory devices

For legacy support, among other factors, IAG has two sets of endpoints for inventory. The first are the /devices and /groups endpoints, which are exclusively for use with Ansible (and Scripts by extension). The second is the /inventories endpoints, which are for all inventory-enabled integrations besides Ansible. In either case, you can manage inventory devices via the GUI or RESTful API endpoints.

Beginning with IAG 2021.1, Ansible will be the only integration that uses the /devices endpoint.

Inventory device integration types

Each Inventory Device has an associated integration_type which is used when managing devices via API calls.

Integration	Integration type
HTTP Requests	http_requests
NETCONF	netconf
Netmiko	netmiko
Nornir	nornir

Device inventory examples

Cisco ASA

1 {
2   "name": XXXXXX
3   "variables":{
4    "ansible_host": "XXX.XX.XXX.XX",
5    "ansible_port": 22,
6    "ansible_network_os": "asa",
7    "ansible_connection": "network_cli",
8    "ansible_user": "USERNAME",
9    "ansible_password": "PASSWORD",
10    "ansible_become": "yes",
11    "ansible_become_method": "enable",
12    "ansible_become_pass": "PASSWORD"
13    }
14 }

Fortigate - Netmiko

1 {
2   "ansible_host": "x.x.x.x",
3   "ansible_user": "user",
4   "ansible_password": "pass",
5   "ansible_port": 22,
6   "ansible_connection": "local",
7   "netmiko_device_type": "fortinet",
8   "get_config_command": "show full-configuration",
9   "end_command": "exit",
10   "get_state_command": "get system status",
11   "save_command": "end"
12 }