Differences between ManageIQ's integration with Ansible Tower and embedded Ansible

ManageIQ’s first integration with Ansible was with an external Ansible Tower added as a provider (Darga Release). The end user would be responsible for creating an Ansible Job Template from Ansible Playbook and ManageIQ would launch the Job Template as part of

  • ManageIQ Service
  • ManageIQ Custom button
  • ManageIQ Post Provisioning

All the Job Template configuration should be done directly on the Ansible Tower most notably the

  • Limit
  • Extra Vars

Starting with Ansible 3.x there is an option in the Ansible Job Template called Prompt on Launch which should be enabled if you want to override either the limit or the extra vars from ManageIQ.

The Limit allows you to limit which hosts the Job Template should run on, if a limit is not specified it would run on all hosts in the Inventory group related to the Job Template.

When run as part of a Custom Button or Post Provisioning the limit would be automatically set to the current vm/instance that we were working with.

In the Fine release we added support for Embedded Ansible, to support execution of Ansible Playbook’s (contrast this with the Tower integration which uses Job Template). Ansible configurations for the following items happens thru ManageIQ UI.

  • Playbook’s
  • Repositories
  • Credentials
  • Creation of Job Template when defining a Service Catalog Item
  • Auto generation of an inventory group during launch

There are no Limits in the Embedded Ansible since, the list of hosts on which the playbook has to be run is controlled by the Auto generation of an inventory group at launch time.
From the ManageIQ perspective everything is wrapped in a Ansible Playbook Service Catalog Item, the job template along with the hosts and extra vars. The Ansible Playbook Service Catalog item became the focal point, you could

  • Order a service when alerts where raised
  • Order a service from Automate Methods
  • Order a service Custom buttons

The fine release also saw us creating service dialogs which could be shared between the Service and Custom buttons, where there was a UI interaction. When run as part of an Alert there would be no user interaction and the default values from the Service dialog would get used.
The playbook’s would get passed in the requester’s token which could be used to interact with our REST API.

In the Gaprindashvilli release we are adding support for running Ansible Playbooks as Automate methods. With this integration the Ansible Playbooks can

  • Get/Set attributes from any object in the Automate Workspace
  • Run as part of Automate State Machine