Limit Inventory to current selection when running Ansible Tower Job


I have integrated ManageIQ with Ansible Tower following the official documentation.

I’m now trying to execute a Tower job template using a button. It works fine, except for one big problem. The inventory in Tower is synced from ManageIQ and contains all VMs (I’m using vSphere).

Is there a way to limit the inventory to only the current selection in ManageIQ? When doing this with Embedded Ansible there is a “Target Machine” option, but not when doing it with Tower.

Would recommend having a read through the following, if you haven’t already.

Thank you @enosullivan for your response .
This is exactly the document I followed, but I missed the Limit part. It seems that I need to manually enter a list of hosts to run against. It certainly helps, but it’s not ideal.
I really thought I was going to be able to just use the current host selection and it would happen automatically like with embedded Ansible, but I guess not.

In this case, would there be any reason not to manually create separate inventories? My landscape consists of dozens of separate systems (several machines each) and they are quite static as far as VMs go, so perhaps instead of using all VMs and manually entering a subset each time, I should prepare the subsets in advance in the form of one inventory for each system. Seems like it will save me time in the long run. Unless I’m missing an important piece of info?

As far as I am aware, yes you need to have an inventory with all your hosts defined, or a dynamic inventory which perhaps links into ManageIQ and pulls a list of servers from there when a job runs.
The server you are clicking the button on would be in that inventory, and the limit variable would make it so that only that server from the inventory is the one that the job is being run against.

That is my interpretation anyways and how it is setup in my team’s environment. Someone else with more knowledge may have an alternative approach, but I believe Ansible Tower always needs some sort of inventory be present.

The book writes:

We can delete the Options box and its Limit element as we don’t need to manually specify these when we call an Ansible job template from a button.

When you press a button, you are already in the context of a VM so you don’t have to specify your target.

If your environment is static, it is a good idea not to sync the inventory all the time (either setup a dynamic inventory but turn off sync or create a manual inventory). This will save you a lot of time running the runbooks and AFAIK only one sync is allowed at a time making concurrent jobs even slower.

Thanks for the pointers @xian. I thought the same, but the thing is, most of my playbooks are run against a set of VMs rather than a single one.
In any case, looks like I’ll just create 20-30 different inventories in Tower (one for each system) and not bother with the Limit field. I’ll just add a dialog to ask me for the inventory on run. This way I’ll avoid syncing inventories and slowing things down.

Thanks all for your replies!

Be careful with using the default JobTemplate operation.
By default ansible_tower_job request calls /ManageIQ/AutomationManagement/AnsibleTower/Operations/JobTemplate/.missing and it will call Operations/StateMachines/Job/default
This default instance calls the wait_for_ip method and this will try to connect to the target in Limit field. If this fails, your Tower job will not run.
I had a similar usecase and finally implemented a workaround by cloning default for my specific jobs and skipping wait_for_ip .

1 Like