Chapter 18. Inventories Red Hat Ansible Automation Platform works against a list of managed nodes or hosts in your infrastructure that are logically organized, using an inventory file. You can use the Red Hat Ansible Automation Platform installer inventory file to specify your installation scenario and describe host deployments to Ansible. By using an inventory file, Ansible can manage a large number of hosts with a single command. Inventories also help you use Ansible more efficiently by reducing the number of command line options you have to specify. Inventories are divided into groups and these groups contain the hosts. Groups may be sourced manually, by entering host names into automation controller, or from one of its supported cloud providers. Note If you have a custom dynamic inventory script, or a cloud provider that is not yet supported natively in automation controller, you can also import that into automation controller. For more information, see Inventory file importing in the Automation controller Administration Guide . From the navigation panel, select Resources Inventories . The Inventories window displays a list of the inventories that are currently available. You can sort the inventory list by Name , Type , or Organization . The Inventory details page includes: Name : The inventory name. Status The statuses are: Success : When the inventory source sync completed successfully Disabled : No inventory source added to the inventory Error : When the inventory source sync completed with error Type : Identifies whether it is a standard inventory, a Smart inventory, or a constructed inventory. Organization : The organization to which the inventory belongs. Actions : The following actions are available for the selected inventory: Edit : Edit the properties for the selected inventory Copy : Makes a copy of an existing inventory as a template for creating a new one Click the Inventory name to display the Details page for the selected inventory, which shows the inventory's groups and hosts. 18.1. Smart Inventories Smart Inventories are collections of hosts defined by a stored search that can be viewed like a standard inventory and can be easily used with job runs. Organization administrators have admin permission for inventories in their organization and can create Smart Inventories. A Smart Inventory is identified by KIND=smart . You can define a Smart Inventory using the same method being used with Search. InventorySource is directly associated with an Inventory. Note Smart inventories are deprecated and will be removed in a future release. Consider moving to constructed inventories for enhancements and replacement. The Inventory model has the following new fields that are blank by default but are set accordingly for Smart Inventories: kind is set to smart for Smart Inventories. host_filter is set AND kind is set to smart for Smart Inventories. The host model has a related endpoint, smart_inventories that identifies a set of all the Smart Inventories a host is associated with. The membership table is updated every time a job runs against a smart inventory. Note To update the memberships more frequently, you can change the AWX_REBUILD_SMART_MEMBERSHIP file-based setting to True . (The default is False). This updates memberships if the following events occur: A new host is added An existing host is modified (updated or deleted) A new Smart Inventory is added An existing Smart Inventory is modified (updated or deleted) You can view inventories without being editable: Names of Host and Group created as a result of an inventory source synchronization. Group records cannot be edited or moved. You cannot create hosts from a Smart Inventory host endpoint ( /inventories/N/hosts/ ) as with a normal inventory. The administrator of a Smart Inventory has permission to edit fields such as the name, description, variables, and the ability to delete, but does not have the permission to modify the host_filter , because that affects which hosts (that have a primary membership inside another inventory) are included in the smart inventory. host_filter only applies to hosts inside of inventories inside the Smart Inventory's organization. To modify host_filter , you must be the organization administrator of the inventory's organization. Organization administrators have implicit "admin" access to all inventories inside the organization, therefore, this does not convey any permissions they did not already possess. Administrators of the Smart Inventory can grant other users (who are not also admins of your organization) permissions such as "use" and "adhoc" to the smart inventory. These permit the actions indicated by the role, as with other standard inventories. However, this does not grant any special permissions to hosts (which live in a different inventory). It does not permit direct read permission to hosts, or permit them to see additional hosts under /#/hosts/ , although they can still view the hosts under the smart inventory host list. In some situations, you can modify the following: A new Host created manually on Inventory with Inventory sources. Groups that were created as a result of inventory source synchronizations. Variables on Host and Group are not changeable, even as the local System Administrator. Hosts associated with the Smart Inventory are manifested at view time. If the results of a Smart Inventory contains more than one host with identical hostnames, only one of the matching hosts is included as part of the Smart Inventory, ordered by Host ID. 18.1.1. Smart Host Filters You can use a search filter to populate hosts for an inventory. This feature uses the fact searching feature. Automation controller stores facts generated by an Ansible Playbook during a Job Template in the database whenever use_fact_cache=True is set per-Job Template. New facts are merged with existing facts and are per-host. These stored facts can be used to filter hosts with the /api/v2/hosts endpoint, using the GET query parameter host_filter . For example: /api/v2/hosts?host_filter=ansible_facts__ansible_processor_vcpus=8 The host_filter parameter permits: grouping with () use of the boolean and operator: __ to reference related fields in relational fields __ is used on ansible_facts to separate keys in a JSON key path `[] is used to denote a json array in the path specification "" can be used in the value when spaces are wanted in the value "classic" Django queries may be embedded in the host_filter Examples: You can search host_filter by host name , group name , and Ansible facts . Group search has the following format: groups.name:groupA Fact search has the following format: ansible_facts.ansible_fips:false You can also perform Smart Search searches, which consist of a host name and host description. host_filter=name=my_host Note If a search term in host_filter is of string type, to make the value a number (for example, 2.66 ) or a JSON keyword (for example, null , true or false ) valid, add double quotations around the value to prevent the controller from parsing it as a non-string: host_filter=ansible_facts__packages__dnsmasq[]__version="2.66" 18.1.2. Defining a host filter with ansible_facts Use the following procedure to use ansible_facts to define the host filter when creating Smart Inventories. Procedure From the navigation panel, select Resources Inventories . Select Add Smart Inventory from Add list. In the Create new smart inventory page, click the icon in the Smart host filter field. This opens a window to filter hosts for this inventory. In the search menu, change the search criteria from Name to Advanced and select ansible_facts from the Key field. If you wanted to add the following ansible fact: /api/v2/hosts/?host_filter=ansible_facts__ansible_processor[]="GenuineIntel" In the search field, enter ansible_processor[]="GenuineIntel" (no extra spaces or __ before the value) and click Enter . The search criteria for the specified ansible fact is displayed. To filter by the regex variable, see the ansible.builtin.regex_search filter documentation, and the KCS article, How to filter hosts not having a particular variable name using regex when creating Smart Inventory . Click Select to add it to the Smart host filter field. Click Save . The Details tab of the new Smart Inventory opens and displays the specified ansible facts in the Smart host filter field. From the Details view, you can edit the Smart host filter field by clicking Edit and delete existing filters, clear all existing filters, or add new ones. 18.2. Constructed Inventories You can create a new inventory (called a constructed inventory) from a list of input inventories. A constructed inventory contains copies of hosts and groups in its input inventories, permitting jobs to target groups of servers across multiple inventories. Groups and hostvars can be added to the inventory content, and hosts can be filtered to limit the size of the constructed inventory. Constructed inventories use the ansible.builtin.constructed inventory model. The key factors of a constructed inventory are: The normal Ansible hostvars namespace is available They provide groups Constructed inventories take source_vars and limit as inputs and transform its input_inventories into a new inventory, complete with groups. Groups (existing or constructed) can then be referenced in the limit field to reduce the number of hosts produced. You can construct groups based on these host properties: RHEL major or minor versions Windows hosts Cloud based instances tagged in a certain region other The following is an example of a constructed inventory details view: The examples described in subsequent sections are organized by the structure of the input inventories. 18.2.1. Filtering on group name and variables You can filter on a combination of groups and variables. For example, you can filter hosts that match a group variable value and also match a host variable value. There are two approaches to executing this filter: Define two groups: one group to match the group variable and the other group to match the host variable value. Use the limit pattern to return the hosts that are in both groups. This is the recommended approach. Define one group. In the definition, include the condition that the group and host variables must match specific values. Use the limit pattern to return all the hosts in the new group. Example: The following inventory file defines four hosts and sets group and host variables. It defines a product group, a sustaining group, and it sets two hosts to a shutdown state. The goal is to create a filter that returns only production hosts that are shutdown. [account_1234] host1 host2 state=shutdown [account_4321] host3 host4 state=shutdown [account_1234:vars] account_alias=product_dev [account_4321:vars] account_alias=sustaining The goal here is to return only shutdown hosts that are present in the group with the account_alias variable equal to product_dev . There are two approaches to this, both shown in YAML format. The first one suggested is recommended. Construct 2 groups, limit to intersection : source_vars : plugin: constructed strict: true groups: is_shutdown: state | default("running") == "shutdown" product_dev: account_alias == "product_dev" limit : is_shutdown:&product_dev This constructed inventory input creates a group for both categories and uses the limit (host pattern) to only return hosts that are in the intersection of those two groups, which is documented in Patterns:targeting hosts and groups . When a variable is or is not defined (depending on the host), you can give a default. For example, use | default("running") if you know what value it should have when it is not defined. This helps with debugging, as described in Debugging tips . Construct 1 group, limit to group : source_vars : plugin: constructed strict: true groups: shutdown_in_product_dev: state | default("running") == "shutdown" and account_alias == "product_dev" limit : shutdown_in_product_dev This input creates one group that only includes hosts that match both criteria. The limit is then just the group name by itself, returning host2 . The same as the earlier approach. 18.2.2. Debugging tips It is important to set the strict parameter to true so that you can debug problems with your templates. If the template fails to render, an error occurs in the associated inventory update for that constructed inventory. When encountering errors, increase verbosity to get more details. Giving a default, such as | default("running") is a generic use of Jinja2 templates in Ansible. Doing this avoids errors from the template when you set strict: true . You can also set strict: false , and so enable the template to produce an error, which results in the host not getting included in that group. However, doing this makes it difficult to debug issues in the future if your templates continue to grow in complexity. You might still have to debug the intended function of the templates if they are not producing the expected inventory content. For example, if a groups group has a complex filter (like shutdown_in_product_dev ) but does not contain any hosts in the resultant constructed inventory, then use the compose parameter to help debug. For example: source_vars: plugin: constructed strict: true groups: shutdown_in_product_dev: state | default("running") == "shutdown" and account_alias == "product_dev" compose: resolved_state: state | default("running") is_in_product_dev: account_alias == "product_dev" limit: `` Running with a blank limit returns all hosts. You can use this to inspect specific variables on specific hosts, giving insight into where problems in the groups lie. 18.2.3. Nested groups A nested group consists of two groups where one is a child of the other. In the following example, the child group has another host inside of it, and the parent group has a variable defined. Because of the way Ansible core operates, the variable of the parent group is available in the namespace as a playbook is running, and can be used for filtering. The following example inventory file, nested.yml is in YAML format: all: children: groupA: vars: filter_var: filter_val children: groupB: hosts: host1: {} ungrouped: hosts: host2: {} Because host1 is in groupB , it is also in groupA . Filter on nested group names Use the following YAML format to filter on nested group names: `source_vars`: plugin: constructed `limit`: `groupA` Filter on nested group property Use the following YAML format to filter on a group variable, even if the host is indirectly a member of that group. In the inventory content, note that host2 is not expected to have the variable filter_var defined, because it is not in any of the groups. Because strict: true is used, use a default value so that hosts without that variable are defined. Using this, host2 , returns false from the expression, instead of producing an error. host1 inherits the variable from its groups, and is returned. source_vars: plugin: constructed strict: true groups: filter_var_is_filter_val: filter_var | default("") == "filter_val" limit: filter_var_is_filter_val 18.2.4. Ansible facts To create an inventory with Ansible facts, you must run a playbook against the inventory that has the setting gather_facts: true . The facts differ system-to-system. The following examples are not intended to address all known scenarios. 18.2.4.1. Filter on environment variables The following example involves filtering on environmental variables using the YAML format: source_vars: plugin: constructed strict: true groups: hosts_using_xterm: ansible_env.TERM == "xterm" limit: hosts_using_xterm 18.2.4.2. Filter hosts by processor type The following example involves filtering hosts by processor type (Intel) using the YAML format: source_vars: plugin: constructed strict: true groups: intel_hosts: "GenuineIntel" in ansible_processor limit: intel_hosts Note Hosts in constructed inventories are not counted against your license allotment because they are referencing the original inventory host. Additionally, hosts that are disabled in the original inventories are not included in the constructed inventory. An inventory update run using ansible-inventory creates the constructed inventory contents. This is always configured to update-on-launch before a job, but you can still select a cache timeout value in case this takes too long. When creating a constructed inventory, the API ensures that it always has one inventory source associated with it. All inventory updates have an associated inventory source, and the fields needed for constructed inventory ( source_vars and limit ) are fields already present on the inventory source model. 18.3. Inventory Plugins Inventory updates use dynamically-generated YAML files which are parsed by their respective inventory plugin. In automation controller v4.4, you can provide the inventory plugin configuration directly to automation controller using the inventory source source_vars for the following inventory sources: Amazon Web Services EC2 Google Compute Engine Microsoft Azure Resource Manager VMware vCenter Red Hat Satellite 6 Red Hat Insights OpenStack Red Hat Virtualization Red Hat Ansible Automation Platform Newly created configurations for inventory sources contain the default plugin configuration values. If you want your newly created inventory sources to match the output of a legacy source, you must apply a specific set of configuration values for that source. To ensure backward compatibility, automation controller uses "templates" for each of these sources to force the output of inventory plugins into the legacy format. For more information on sources and their respective templates, see Supported inventory plugin templates . source_vars that contain plugin: foo.bar.baz as a top-level key are replaced with the fully-qualified inventory plugin name at runtime based on the InventorySource source. For example, if ec2 is selected for the InventorySource then, at run-time, plugin is set to amazon.aws.aws_ec2 . 18.4. Add a new inventory Adding a new inventory involves the following components: Adding permissions to inventories Adding groups to inventories Adding a host Adding a source View completed jobs Use the following procedure to create an inventory: Procedure From the navigation panel, select Resources Inventories . The Inventories window displays a list of the inventories that are currently available. Click Add , and select the type of inventory to create. Enter the appropriate details into the following fields: Name : Enter a name appropriate for this inventory. Optional: Description : Enter an arbitrary description as appropriate. Organization : Required. Choose among the available organizations. Only applicable to Smart Inventories: Smart Host Filter : Click the icon to open a separate window to filter hosts for this inventory. These options are based on the organization you chose. Filters are similar to tags in that tags are used to filter certain hosts that contain those names. Therefore, to populate the Smart Host Filter field, specify a tag that contains the hosts you want, not the hosts themselves. Enter the tag in the Search field and click Enter . Filters are case-sensitive. For more information, see Smart host filters . Instance Groups : Click the icon to open a separate window. Select the instance group or groups for this inventory to run on. If the list is extensive, use the search to narrow the options. You can select multiple instance groups and sort them in the order that you want them run. Optional: Labels : Supply labels that describe this inventory, so they can be used to group and filter inventories and jobs. Only applicable to constructed inventories: Input inventories : Specify the source inventories to include in this constructed inventory. Click the icon to select from available inventories. Empty groups from input inventories are copied into the constructed inventory. Optional:(Only applicable to constructed inventories): Cached timeout (seconds) : Set the length of time you want the cache plugin data to timeout. Only applicable to constructed inventories: Verbosity : Control the level of output that Ansible produces as the playbook executes related to inventory sources associated with constructed inventories. Select the verbosity from Normal to various Verbose or Debug settings. This only appears in the "details" report view. Verbose logging includes the output of all commands. Debug logging is exceedingly verbose and includes information on SSH operations that can be useful in certain support instances. Most users do not need to see debug mode output. Only applicable to constructed inventories: Limit : Restricts the number of returned hosts for the inventory source associated with the constructed inventory. You can paste a group name into the limit field to only include hosts in that group. For more information, ses the Source vars setting. Only applicable to standard inventories: Options : Check the Prevent Instance Group Fallback option to enable only the instance groups listed in the Instance Groups field to execute the job. If unchecked, all available instances in the execution pool will be used based on the hierarchy described in Control where a job runs in the Automation controller Administration Guide . Click the icon for additional information. Note Set the prevent_instance_group_fallback option for Smart Inventories through the API. Variables ( Source vars for constructed inventories): Variables Variable definitions and values to apply to all hosts in this inventory. Enter variables using either JSON or YAML syntax. Use the radio button to toggle between the two. Source vars for constructed inventories creates groups, specifically under the groups key of the data. It accepts Jinja2 template syntax, renders it for every host, makes a true or false evaluation, and includes the host in the group (from the key of the entry) if the result is true . This is particularly useful because you can paste that group name into the limit field to only include hosts in that group. See Example 1 in Smart host filters . Click Save . After saving the new inventory, you can proceed with configuring permissions, groups, hosts, sources, and view completed jobs, if applicable to the type of inventory. 18.4.1. Adding permissions to inventories Use the following procedure to add permissions to inventories: Procedure From the navigation panel, select Resources Inventories . Select a template, and in the Access tab , click Add . Select a user or team to add and click . Select the check box to a name to add one or more users or teams from the list as members. Click . In this example, two users have been selected to be added. Select the roles you want the selected users or teams to have. Scroll down for a complete list of roles. Different resources have different options available. Click Save to apply the roles to the selected users or teams and to add them as members. The Add Users or Teams window closes to display the updated roles assigned for each user and team. Removing a permission To remove roles for a particular user, click the icon to its resource. This launches a confirmation window, asking you to confirm the disassociation. 18.4.2. Adding groups to inventories Inventories are divided into groups, which can contain hosts and other groups. Groups are only applicable to standard inventories and are not a configurable directly through a Smart Inventory. You can associate an existing group through hosts that are used with standard inventories. The following actions are available for standard inventories: Create a new Group Create a new Host Run a command on the selected Inventory Edit Inventory properties View activity streams for Groups and Hosts Obtain help building your Inventory Note Inventory sources are not associated with groups. Spawned groups are top-level and can still have child groups. All of these spawned groups can have hosts. Use the following procedure to create a new group for an inventory: Procedure Select the Inventory name you want to add groups to. In the Inventory Details page, select the Groups tab. Click Add to open the Create Group window. Enter the appropriate details: Name : Required Optional: Description : Enter a description as appropriate. Variables : Enter definitions and values to be applied to all hosts in this group. Enter variables using either JSON or YAML syntax. Use the radio button to toggle between the two. Click Save . When you have added a group to a template, the Group details page is displayed. 18.4.2.1. Adding groups within groups Use the following procedure to add groups within groups: Procedure When you have added a group to a template, the Group details page is displayed. Select the Related Groups tab. Click Add . Select whether to add a group that already exists in your configuration or create a new group. If creating a new group, enter the appropriate details into the required and optional fields: Name (required): Optional: Description : Enter a description as appropriate. Variables : Enter definitions and values to be applied to all hosts in this group. Enter variables using either JSON or YAML syntax. Use the radio button to toggle between the two. Click Save . The Create Group window closes and the newly created group is displayed as an entry in the list of groups associated with the group that it was created for. If you choose to add an existing group, available groups appear in a separate selection window. When a group is selected, it is displayed in the list of groups associated with the group. To configure additional groups and hosts under the subgroup, click the name of the subgroup from the list of groups and repeat the steps listed in this section. 18.4.2.2. View or edit inventory groups The groups list view displays all your inventory groups, or you can filter it to only display the root groups. An inventory group is considered a root group if it is not a subset of another group. You can delete a subgroup without concern for dependencies, because automation controller looks for dependencies such as child groups or hosts. If any exist, a confirmation window displays for you to choose whether to delete the root group and all of its subgroups and hosts; or to promote the subgroups so they become the top-level inventory groups, along with their hosts. 18.4.3. Adding hosts to an inventory You can configure hosts for the inventory as well as for groups and groups within groups. Use the following procedure to add hosts: Procedure Select the Inventory name you want to add groups to. In the Inventory Details page, select the Hosts tab. Click Add . Select whether to add a host that already exists in your configuration or create a new host. If creating a new host, set the toggle to On to include this host while running jobs. Enter the appropriate details: Host Name (required): Optional: Description : Enter a description as appropriate. Variables : Enter definitions and values to be applied to all hosts in this group, as in the following example: { ansible_user : <username to ssh into> ansible_ssh_pass : <password for the username> ansible_become_pass: <password for becoming the root> } Enter variables using either JSON or YAML syntax. Use the radio button to toggle between the two. Click Save . The Create Host window closes and the newly created host is displayed in the list of hosts associated with the group that it was created for. If you choose to add an existing host, available hosts appear in a separate selection window. When a host is selected, it is displayed in the list of hosts associated with the group. You can disassociate a host from this screen by selecting the host and clicking the icon. Note You can also run ad hoc commands from this screen. For more information, see [Running ad hoc commands]. To configure additional groups for the host, click the name of the host from the list of hosts. This opens the Details tab of the selected host. Select the Groups tab to configure groups for the host. Click Add to associate the host with an existing group. Available groups appear in a separate selection window. Select the groups to associate with the host and click Save . When a group is associated, it is displayed in the list of groups associated with the host. If a host was used to run a job, you can view details about those jobs in the Completed Jobs tab of the host. Click Expanded to view details about each job. Note You can create hosts in bulk using the newly added endpoint in the API, /api/v2/bulk/host_create . This endpoint accepts JSON and you can specify the target inventory and a list of hosts to add to the inventory. These hosts must be unique within the inventory. Either all hosts are added, or an error is returned indicating why the operation was not able to complete. Use the OPTIONS request to return the relevant schema. For more information, see Bulk endpoints in the Automation Controller API Guide . 18.4.4. Adding a source Inventory sources are not associated with groups. Spawned groups are top-level and can still have child groups. All of these spawned groups can have hosts. Adding a source to an inventory only applies to standard inventories. Smart inventories inherit their source from the standard inventories they are associated with. Use the following procedure to configure the source for the inventory: Procedure Select the Inventory name you want to add a source to. In the Inventory Details page, select the Sources tab. Click Add . This opens the Create Source window. Enter the appropriate details: Name (required): Optional: Description : Enter a description as appropriate. Optional: Execution Environment : Click the icon or enter the name of the execution environment with which you want to run your inventory imports. For more information on building an execution environment, see Execution environments . Source : Choose a source for your inventory. For more information on sources, and supplying the appropriate information, see Inventory sources . When the information for your chosen Inventory sources is complete, you can optionally specify other common parameters, such as verbosity, host filters, and variables. Use the Verbosity menu to select the level of output on any inventory source's update jobs. Use the Host Filter field to specify only matching host names to be imported into automation controller. In the Enabled Variable field, specify that automation controller retrieves the enabled state from the dictionary of host variables. You can specify the enabled variable using dot notation as 'foo.bar', in which case the lookup searches nested dictionaries, equivalent to: from_dict.get('foo', {}).get('bar', default) . If you specified a dictionary of host variables in the Enabled Variable field, you can provide a value to enable on import. For example, for enabled_var='status.power_state' and 'enabled_value='powered_on' in the following host variables, the host is marked enabled : { "status": { "power_state": "powered_on", "created": "2020-08-04T18:13:04+00:00", "healthy": true }, "name": "foobar", "ip_address": "192.168.2.1" } If power_state is any value other than powered_on , then the host is disabled when imported into automation controller. If the key is not found, then the host is enabled. All cloud inventory sources have the following update options: Overwrite : If checked, any hosts and groups that were previously present on the external source but are now removed, are removed from the automation controller inventory. Hosts and groups that were not managed by the inventory source are promoted to the manually created group, or, if there is no manually created group to promote them into, they are left in the "all" default group for the inventory. When not checked, local child hosts and groups not found on the external source remain untouched by the inventory update process. Overwrite Variables : If checked, all variables for child groups and hosts are removed and replaced by those found on the external source. When not checked, a merge is performed, combining local variables with those found on the external source. Update on Launch : Each time a job runs using this inventory, refresh the inventory from the selected source before executing job tasks. To avoid job overflows if jobs are spawned faster than the inventory can synchronize, selecting this enables you to configure a Cache Timeout to cache inventory synchronizations for a certain number of seconds. The Update on Launch setting refers to a dependency system for projects and inventory, and does not specifically exclude two jobs from running at the same time. If a cache timeout is specified, then the dependencies for the second job are created, and it uses the project and inventory update that the first job spawned. Both jobs then wait for that project or inventory update to finish before proceeding. If they are different job templates, they can then both start and run at the same time, if the system has the capacity to do so. If you intend to use automation controller's provisioning callback feature with a dynamic inventory source, Update on Launch must be set for the inventory group. If you synchronize an inventory source that uses a project that has Update On Launch set, then the project might automatically update (according to cache timeout rules) before the inventory update starts. You can create a job template that uses an inventory that sources from the same project that the template uses. In such a case, the project updates and then the inventory updates (if updates are not already in progress, or if the cache timeout has not already expired). Review your entries and selections. This enables you to configure additional details, such as schedules and notifications. To configure schedules associated with this inventory source, click the Schedules tab: If schedules are already set up, then review, edit, enable or disable your schedule preferences. If schedules have not been set up, for more information about setting up schedules, see Schedules . 18.4.5. Configuring notifications for the source Use the following procedure to configure notifications for the source: In the Inventory Details page, select the Notifications tab. Note The Notifications tab is only present when you have saved the newly-created source. If notifications are already set up, use the toggles to enable or disable the notifications to use with your particular source. For more information, see Enable and Disable Notifications . If notifications have not been set up, see Notifications for more information. Review your entries and selections. Click Save . When a source is defined, it is displayed in the list of sources associated with the inventory. From the Sources tab you can perform a sync on a single source, or sync all of them at once. You can also perform additional actions such as scheduling a sync process, and edit or delete the source. 18.4.5.1. Inventory sources Choose a source which matches the inventory type against which a host can be entered: Sourcing from a Project Amazon Web Services EC2 Google Compute Engine Microsoft Azure Resource Manager VMware vCenter Red Hat Satellite 6 Red Hat Insights OpenStack Red Hat Virtualization Red Hat Ansible Automation Platform 18.4.5.1.1. Sourcing from a Project An inventory that is sourced from a project means that it uses the SCM type from the project it is tied to. For example, if the project's source is from GitHub, then the inventory uses the same source. Use the following procedure to configure a project-sourced inventory: Procedure In the Create new source page, select Sourced from a Project from the Source list. The Create Source window expands with additional fields. Enter the following details: Optional: Source Control Branch/Tag/Commit : Enter the SCM branch, tags, commit hashes, arbitrary refs, or revision number (if applicable) from the source control (Git or Subversion) to checkout. This field only displays if the sourced project has the Allow Branch Override option checked. For further information, see SCM Types - Git and Subversion . Some commit hashes and refs might not be available unless you also provide a custom refspec in the field. If left blank, the default is HEAD which is the last checked out Branch/Tag/Commit for this project. Optional: Credential : Specify the credential to use for this source. Project (required): Pre-populates with a default project, otherwise, specify the project this inventory is using as its source. Click the icon to choose from a list of projects. If the list is extensive, use the search to narrow the options. Inventory File (required): Select an inventory file associated with the sourced project. If not already populated, you can type it into the text field within the menu to filter extraneous file types. In addition to a flat file inventory, you can point to a directory or an inventory script. Optional: You can specify the verbosity, host filter, enabled variable/value, and update options as described in Adding a source . Optional: To pass to the custom inventory script, you can set environment variables in the Environment Variables field. You can also place inventory scripts in source control and then run it from a project. For more information, see Inventory File Importing in Automation controller Administration Guide . Note If you are executing a custom inventory script from SCM, ensure that you set the execution bit ( chmod +x ) for the script in your upstream source control. If you do not, automation controller throws a [Errno 13] Permission denied error on execution. 18.4.5.1.2. Amazon Web Services EC2 Use the following procedure to configure an AWS EC2-sourced inventory, Procedure In the Create new source page, select Amazon EC2 from the Source list. The Create Source window expands with additional fields. Enter the following details: Optional: Credential : Choose from an existing AWS credential (for more information, see Credentials ). If automation controller is running on an EC2 instance with an assigned IAM Role, the credential can be omitted, and the security credentials from the instance metadata are used instead. For more information on using IAM Roles, see IAM_Roles_for_Amazon_EC2_documentation_at_Amazon . Optional: You can specify the verbosity, host filter, enabled variables or values, and update options as described in Adding a source . Use the Source Variables field to override variables used by the aws_ec2 inventory plugin. Enter variables using either JSON or YAML syntax. Use the radio button to toggle between the two. For more information on these variables, see the aws inventory plugin documentation . Note If you only use include_filters , the AWS plugin always returns all the hosts. To use this correctly, the first condition on the or must be on filters and then build the rest of the OR conditions on a list of include_filters . 18.4.5.1.3. Google Compute Engine Use the following procedure to configure a Google-sourced inventory. Procedure In the Create new source page, select Google Compute Engine from the Source . The Create Source window expands with the required Credential field. Choose from an existing GCE Credential. For more information, see Credentials . Optional: You can specify the verbosity, host filter, enabled variables or values, and update options as described in Adding a source . Use the Source Variables field to override variables used by the gcp_compute inventory plugin. Enter variables using either JSON or YAML syntax. Use the radio button to toggle between the two. For more information on these variables, see the gcp_compute inventory plugin documentation . 18.4.5.1.4. Microsoft Azure resource manager Use the following procedure to configure an Azure Resource Manager-sourced inventory: Procedure In the Create new source page, select Microsoft Azure Resource Manager from the Source list. The Create Source window expands with the required Credential field. Choose from an existing Azure Credential. For more information, see Credentials . Optional: You can specify the verbosity, host filter, enabled variables or values, and update options as described in Adding a source . Use the Source Variables field to override variables used by the azure_rm inventory plugin. Enter variables using either JSON or YAML syntax. Use the radio button to toggle between the two. For more information on these variables, see the azure_rm inventory plugin documentation . 18.4.5.1.5. VMware vCenter Use the following procedure to configure a VMWare-sourced inventory. Procedure In the Create new source page, select VMware vCenter from the Source list. The Create Source window expands with the required Credential field. Choose from an existing VMware Credential. For more information, see Credentials . Optional: You can specify the verbosity, host filter, enabled variables or values, and update options as described in Adding a source . Use the Source Variables field to override variables used by the vmware_inventory inventory plugin. Enter variables using either JSON or YAML syntax. Use the radio button to toggle between the two. For more information on these variables, see the vmware_inventory inventory plugin . Note VMWare properties have changed from lower case to camelCase. Automation controller provides aliases for the top-level keys, but lower case keys in nested properties have been discontinued. For a list of valid and supported properties, refer to Using Virtual machine attributes in VMware dynamic inventory plugin . 18.4.5.1.6. Red Hat Satellite 6 Use the following procedure to configure a Red Hat Satellite-sourced inventory. Procedure In the Create new source page, select Red Hat Satellite from the Source list. The Create Source window expands with the required Credential field. Choose from an existing Satellite Credential. For more information, see Credentials . Optional: You can specify the verbosity, host filter, enabled variables or values, and update options as described in Adding a source . Use the Source Variables field to specify parameters used by the foreman inventory source. Enter variables using either JSON or YAML syntax. Use the radio button to toggle between the two. For more information on these variables, see the Foreman inventory source in the Ansible documentation. If you encounter an issue with the automation controller inventory not having the "related groups" from Satellite, you might need to define these variables in the inventory source. For more information, see Red Hat Satellite 6 . If you see the message, "no foreman.id" variable(s) when syncing the inventory , refer to the solution on the Red Hat Customer Portal at: https://access.redhat.com/solutions/5826451 . Be sure to login with your customer credentials to access the full article. 18.4.5.1.7. Red Hat Insights Use the following procedure to configure a Red Hat Insights-sourced inventory. Procedure In the Create new source page, select Red Hat Insights from the Source list. The Create Source window expands with the required Credential field. Choose from an existing Red Hat Insights Credential. For more information, see Credentials . Optional: You can specify the verbosity, host filter, enabled variables or values, and update options as described in Adding a source . Use the Source Variables field to override variables used by the insights inventory plugin. Enter variables by using either JSON or YAML syntax. Use the radio button to toggle between the two. For more information about these variables, see insights inventory plugin . 18.4.5.1.8. OpenStack Use the following procedure to configure an OpenStack-sourced inventory. Procedure In the Create new source page, select Openstack from the Source list. The Create Source window expands with the required Credential field. Choose from an existing OpenStack Credential. For more information, see Credentials . Optional: You can specify the verbosity, host filter, enabled variables or values, and update options as described in Adding a source . Use the Source Variables field to override variables used by the openstack inventory plugin. Enter variables by using either JSON or YAML syntax. Use the radio button to toggle between the two. For more information about these variables, see openstack inventory plugin . 18.4.5.1.9. Red hat virtualization Use the following procedure to configure a Red Hat virtualization-sourced inventory. Procedure In the Create new source page, select Red Hat Virtualization from the Source list. The Create Source window expands with the required Credential field. Choose from an existing Red Hat Virtualization Credential. For more information, see Credentials . Optional: You can specify the verbosity, host filter, enabled variables or values, and update options as described in Adding a source . Use the Source Variables field to override variables used by the ovirt inventory plugin. Enter variables by using either JSON or YAML syntax. Use the radio button to toggle between the two. For more information about these variables, see ovirt inventory plugin Note Red Hat Virtualization (ovirt) inventory source requests are secure by default. To change this default setting, set the key ovirt_insecure to true in source_variables , which is only available from the API details of the inventory source at the /api/v2/inventory_sources/N/ endpoint. 18.4.5.1.10. Red Hat Ansible Automation Platform Use the following procedure to configure an automation controller-sourced inventory. Procedure In the Create new source page, select Red Hat Ansible Automation Platform from the *Source list. The Create Source window expands with the required Credential field. Choose from an existing Red Hat Ansible Automation Platform. For more information, see Credentials . Optional: You can specify the verbosity, host filter, enabled variables or values, and update options as described in Adding a source . Use the Source Variables field to override variables used by the controller inventory plugin. Enter variables by using either JSON or YAML syntax. Use the radio button to toggle between the two. For more information about these variables, see Controller inventory plugin . This requires your Red Hat Customer login. 18.4.5.2. Export old inventory scripts Despite the removal of the custom inventory scripts API, the scripts are still saved in the database. The commands described in this section enable you to recover the scripts from the database in a format that is suitable for you to subsequently check into source control. Use the following commands: USD awx-manage export_custom_scripts --filename=my_scripts.tar Dump of old custom inventory scripts at my_scripts.tar Making use of the output: USD mkdir my_scripts USD tar -xf my_scripts.tar -C my_scripts The name of the scripts has the form: <pk>_ <name> . This is the naming scheme used for project folders. USD ls my_scripts 10 inventory_script_rawhook _19 _30 inventory_script_listenhospital _11 inventory_script_upperorder _1 inventory_script_commercialinternet45 _4 inventory_script_whitestring _12 inventory_script_eastplant _22 inventory_script_pinexchange _5 inventory_script_literaturepossession _13 inventory_script_governmentculture _23 inventory_script_brainluck _6 inventory_script_opportunitytelephone _14 inventory_script_bottomguess _25 inventory_script_buyerleague _7 inventory_script_letjury _15 inventory_script_wallisland _26 inventory_script_lifesport _8 random_inventory_script 16 inventory_script_wallisland _27 inventory_script_exchangesomewhere _9 random_inventory_script _17 inventory_script_bidstory _28 inventory_script_boxchild _18 p _29__inventory_script_wearstress Each file contains a script. Scripts can be bash/python/ruby/more , so the extension is not included. They are all directly executable. Executing the script dumps the inventory data. USD ./my_scripts/ 11__inventory_script_upperorder {"group \ud801\udcb0\uc20e\u7b0e\ud81c\udfeb\ub12b\ub4d0\u9ac6\ud81e\udf07\u6ff9\uc17b": {"hosts": ["host_\ud821\udcad\u68b6\u7a51\u93b4\u69cf\uc3c2\ud81f\uddbe\ud820\udc92\u3143\u62c7", "host_\u6057\u3985\u1f60\ufefb\u1b22\ubd2d\ua90c\ud81a\udc69\u1344\u9d15", "host_\u78a0\ud820\udef3\u925e\u69da\ua549\ud80c\ude7e\ud81e\udc91\ud808\uddd1\u57d6\ud801\ude57", "host_\ud83a\udc2d\ud7f7\ua18a\u779a\ud800\udf8b\u7903\ud820\udead\u4154\ud808\ude15\u9711", "host_\u18a1\u9d6f\u08ac\u74c2\u54e2\u740e\u5f02\ud81d\uddee\ufbd6\u4506"], "vars": {"ansible_host": "127.0.0.1", "ansible_connection": "local"}}} You can verify functionality with ansible-inventory . This gives the same data, but reformatted. USD ansible-inventory -i ./my_scripts/_11__inventory_script_upperorder --list --export In the preceding example, you can cd into my_scripts and then issue a git init command, add the scripts you want, push it to source control, and then create an SCM inventory source in the user interface. For more information on syncing or using custom inventory scripts, see Inventory file importing in the Automation controller Administration Guide . 18.5. View completed jobs If an inventory was used to run a job, you can view details about those jobs in the Completed Jobs tab of the inventory and click Expanded to view details about each job. 18.6. Running Ad Hoc commands Ad hoc refers to using Ansible to perform a quick command, using /usr/bin/ansible, rather than the orchestration language, which is /usr/bin/ansible-playbook. An example of an ad hoc command might be rebooting 50 machines in your infrastructure. Anything you can do ad hoc can be accomplished by writing a Playbook. Playbooks can also glue lots of other operations together. Use the following procedure to run an ad hoc command: Procedure Select an inventory source from the list of hosts or groups. The inventory source can be a single group or host, a selection of multiple hosts, or a selection of multiple groups. Click Run Command . The Run command window opens. Enter the following information: Module : Select one of the modules that the supports running commands against. command apt_repository mount win_service shell apt_rpm ping win_updates yum service selinux win_group apt group setup win_user apt_key user win_ping win_user Arguments : Provide arguments to be used with the module you selected. Limit : Enter the limit used to target hosts in the inventory. To target all hosts in the inventory enter all or * , or leave the field blank. This is automatically populated with whatever was selected in the view before clicking the launch button. Machine Credential : Select the credential to use when accessing the remote hosts to run the command. Choose the credential containing the username and SSH key or password that Ansible needs to log in to the remote hosts. Verbosity : Select a verbosity level for the standard output. Forks : If needed, select the number of parallel or simultaneous processes to use while executing the command. Show Changes : Select to enable the display of Ansible changes in the standard output. The default is OFF. Enable Privilege Escalation : If enabled, the playbook is run with administrator privileges. This is the equivalent of passing the --become option to the ansible command. Extra Variables : Provide extra command line variables to be applied when running this inventory. Enter variables using either JSON or YAML syntax. Use the radio button to toggle between the two. Click to choose the execution environment you want the ad hoc command to be run against. Click to choose the credential you want to use. Click Launch . The results display in the Output tab of the module's job window.

Commands:
/api/v2/hosts?host_filter=ansible_facts__ansible_processor_vcpus=8
/api/v2/hosts/?host_filter=name=localhost /api/v2/hosts/?host_filter=ansible_facts__ansible_date_time__weekday_number="3" /api/v2/hosts/?host_filter=ansible_facts__ansible_processor[]="GenuineIntel" /api/v2/hosts/?host_filter=ansible_facts__ansible_lo__ipv6[]__scope="host" /api/v2/hosts/?host_filter=ansible_facts__ansible_processor_vcpus=8 /api/v2/hosts/?host_filter=ansible_facts__ansible_env__PYTHONUNBUFFERED="true" /api/v2/hosts/?host_filter=(name=localhost or name=database) and (groups__name=east or groups__name="west coast") and ansible_facts__an
groups.name:groupA
ansible_facts.ansible_fips:false
host_filter=name=my_host
host_filter=ansible_facts__packages__dnsmasq[]__version="2.66"
/api/v2/hosts/?host_filter=ansible_facts__ansible_processor[]="GenuineIntel"
[account_1234] host1 host2 state=shutdown [account_4321] host3 host4 state=shutdown [account_1234:vars] account_alias=product_dev [account_4321:vars] account_alias=sustaining
plugin: constructed strict: true groups: is_shutdown: state | default("running") == "shutdown" product_dev: account_alias == "product_dev"
plugin: constructed strict: true groups: shutdown_in_product_dev: state | default("running") == "shutdown" and account_alias == "product_dev"
source_vars: plugin: constructed strict: true groups: shutdown_in_product_dev: state | default("running") == "shutdown" and account_alias == "product_dev" compose: resolved_state: state | default("running") is_in_product_dev: account_alias == "product_dev" limit: ``
all: children: groupA: vars: filter_var: filter_val children: groupB: hosts: host1: {} ungrouped: hosts: host2: {}
`source_vars`: plugin: constructed `limit`: `groupA`
source_vars: plugin: constructed strict: true groups: filter_var_is_filter_val: filter_var | default("") == "filter_val" limit: filter_var_is_filter_val
source_vars: plugin: constructed strict: true groups: hosts_using_xterm: ansible_env.TERM == "xterm" limit: hosts_using_xterm
source_vars: plugin: constructed strict: true groups: intel_hosts: "GenuineIntel" in ansible_processor limit: intel_hosts
{ ansible_user : <username to ssh into> ansible_ssh_pass : <password for the username> ansible_become_pass: <password for becoming the root> }
{ "status": { "power_state": "powered_on", "created": "2020-08-04T18:13:04+00:00", "healthy": true }, "name": "foobar", "ip_address": "192.168.2.1" }
awx-manage export_custom_scripts --filename=my_scripts.tar Dump of old custom inventory scripts at my_scripts.tar
mkdir my_scripts tar -xf my_scripts.tar -C my_scripts
ls my_scripts 10 inventory_script_rawhook _19 _30 inventory_script_listenhospital _11 inventory_script_upperorder _1 inventory_script_commercialinternet45 _4 inventory_script_whitestring _12 inventory_script_eastplant _22 inventory_script_pinexchange _5 inventory_script_literaturepossession _13 inventory_script_governmentculture _23 inventory_script_brainluck _6 inventory_script_opportunitytelephone _14 inventory_script_bottomguess _25 inventory_script_buyerleague _7 inventory_script_letjury _15 inventory_script_wallisland _26 inventory_script_lifesport _8 random_inventory_script 16 inventory_script_wallisland _27 inventory_script_exchangesomewhere _9 random_inventory_script _17 inventory_script_bidstory _28 inventory_script_boxchild _18 p _29__inventory_script_wearstress
./my_scripts/ 11__inventory_script_upperorder {"group \ud801\udcb0\uc20e\u7b0e\ud81c\udfeb\ub12b\ub4d0\u9ac6\ud81e\udf07\u6ff9\uc17b": {"hosts": ["host_\ud821\udcad\u68b6\u7a51\u93b4\u69cf\uc3c2\ud81f\uddbe\ud820\udc92\u3143\u62c7", "host_\u6057\u3985\u1f60\ufefb\u1b22\ubd2d\ua90c\ud81a\udc69\u1344\u9d15", "host_\u78a0\ud820\udef3\u925e\u69da\ua549\ud80c\ude7e\ud81e\udc91\ud808\uddd1\u57d6\ud801\ude57", "host_\ud83a\udc2d\ud7f7\ua18a\u779a\ud800\udf8b\u7903\ud820\udead\u4154\ud808\ude15\u9711", "host_\u18a1\u9d6f\u08ac\u74c2\u54e2\u740e\u5f02\ud81d\uddee\ufbd6\u4506"], "vars": {"ansible_host": "127.0.0.1", "ansible_connection": "local"}}}
ansible-inventory -i ./my_scripts/_11__inventory_script_upperorder --list --export