Chapter 4. Inventory File Importing Automation controller enables you to choose an inventory file from source control, rather than creating one from scratch. This function is the same as for custom inventory scripts, except that the contents are obtained from source control instead of editing their contents in a browser. This means that the files are non-editable, and as inventories are updated at the source, the inventories within the projects are also updated accordingly, including the group_vars and host_vars files or directory associated with them. SCM types can consume both inventory files and scripts. Both inventory files and custom inventory types use scripts. Imported hosts have a description of imported by default. This can be overridden by setting the _awx_description variable on a given host. For example, if importing from a sourced .ini file, you can add the following host variables: [main] 127.0.0.1 _awx_description="my host 1" 127.0.0.2 _awx_description="my host 2" Similarly, group descriptions also default to imported , but can also be overridden by _awx_description . To use old inventory scripts in source control, see Export old inventory scripts in the Automation controller User Guide . 4.1. Custom Dynamic Inventory Scripts A custom dynamic inventory script stored in version control can be imported and run. This makes it much easier to make changes to an inventory script. Rather than having to copy and paste a script into automation controller, it is pulled directly from source control and then executed. The script must handle any credentials required for its task. You are responsible for installing any Python libraries required by the script. (Custom dynamic inventory scripts have the same requirement.) This applies to both user-defined inventory source scripts and SCM sources as they are both exposed to Ansible virtualenv requirements related to playbooks. You can specify environment variables when you edit the SCM inventory source. For some scripts, this is sufficient. However, this is not a secure way to store secret information that gives access to cloud providers or inventory. A better way is to create a new credential type for the inventory script you are going to use. The credential type must specify all the necessary types of inputs. Then, when you create a credential of this type, the secrets are stored in an encrypted form. If you apply that credential to the inventory source, the script has access to those inputs. For more information, see Custom Credential Types in the Automation controller User Guide. 4.2. SCM Inventory Source Fields The source fields used are: source_project : the project to use. source_path : the relative path inside the project indicating a directory or a file. If left blank, "" is still a relative path indicating the root directory of the project. source_vars : if set on a "file" type inventory source then they are passed to the environment variables when running. Additionally: An update of the project automatically triggers an inventory update where it is used. An update of the project is scheduled immediately after creation of the inventory source. Neither inventory nor project updates are blocked while a related job is running. In cases where you have a large project (around 10 GB), disk space on /tmp can be an issue. You can specify a location manually in the automation controller UI from the Create Inventory Source page. Refer to Adding a source for instructions on creating an inventory source. When you update a project, refresh the listing to use the latest SCM information. If no inventory sources use a project as an SCM inventory source, then the inventory listing might not be refreshed on update. For inventories with SCM sources, the Job Details page for inventory updates displays a status indicator for the project update and the name of the project. The status indicator links to the project update job. The project name links to the project. You can perform an inventory update while a related job is running. 4.2.1. Supported File Syntax Automation controller uses the ansible-inventory module from Ansible to process inventory files, and supports all valid inventory syntax that automation controller requires. Important You do not need to write inventory scripts in Python. You can enter any executable file in the source field and must run chmod +x for that file and check it into Git. The following is a working example of JSON output that automation controller can read for the import: { "_meta": { "hostvars": { "host1": { "fly_rod": true } } }, "all": { "children": [ "groupA", "ungrouped" ] }, "groupA": { "hosts": [ "host1", "host10", "host11", "host12", "host13", "host14", "host15", "host16", "host17", "host18", "host19", "host2", "host20", "host21", "host22", "host23", "host24", "host25", "host3", "host4", "host5", "host6", "host7", "host8", "host9" ] } } Additional resources For examples of inventory files, see test-playbooks/inventories . For an example of an inventory script inside of that, see inventories/changes.py . For information about how to implement the inventory script, see the support article, How to migrate inventory scripts from Red Hat Ansible tower to Red Hat Ansible Automation Platform? .

Commands:
[main] 127.0.0.1 _awx_description="my host 1" 127.0.0.2 _awx_description="my host 2"
{ "_meta": { "hostvars": { "host1": { "fly_rod": true } } }, "all": { "children": [ "groupA", "ungrouped" ] }, "groupA": { "hosts": [ "host1", "host10", "host11", "host12", "host13", "host14", "host15", "host16", "host17", "host18", "host19", "host2", "host20", "host21", "host22", "host23", "host24", "host25", "host3", "host4", "host5", "host6", "host7", "host8", "host9" ] } }