Launching Ansible Tower Job Templates from ManageIQ

[mkanoor]

In the Darga release we have added support for Ansible Tower Job Templates, as part of this feature an Ansible Tower is added as a Provider and we fetch the Inventory and Job Templates information from Ansible Tower and store it in VMDB.

The use case presented here will

Launch an Ansible Job Template from a button in ManageIQ

Pre Requisites:

(1) Both Ansible Tower and the ManageIQ should be working with the same providers.

(2) The inventory group in Ansible should have “Update on Launch” enabled, this allows Ansible to update its inventory with the newly provisioned VM before it launches the job.


Add Ansible Tower as a provider

          Configuration -> Configuration Management -> Configuration -> Add a new Provider

          URL => https://<ansible_tower>/api/v1

          After the Provider has been added

          Configuration -> Refresh Relationships and Power States

          Wait for the Refresh to end.

New automate classes for supporting Ansible Tower Job Templates

/ManageIQ/ConfigurationManagement/AnsibleTower/Operations
JobTemplate:

 * Name of Job Template
 * Parameters .... for the Job Template
 * Launch the State Machine to execute the Job Template

A place holder missing instance has been provided that uses the instance name to set the name of the job template.

/ManageIQ/ConfigurationManagement/AnsibleTower/Operations/StateMachines
Job:

   * WaitForIP                 Waits for the VM to be powered on and ip address
   * Launch                    Launch the ansible job
   * WaitForCompletion         Wait for the job template to end 

Creating a new button for VM’s

Navigate to Automate -> Customizations -> Buttons -> VM and Instance
Select the Unassigned Buttons folder
Add a new Button

Please note that the Object Details section should have
System/Process = Request
Message = create
Request = Ansible_Tower_Job

Just like in the picture above.

You specify the name of your Job Template in the Attribute/Value Pairs section

job_template_name

is the parameter that stores the name of your template associated with this button.

Assign the button to the VM Actions

Buttons -> VM and Instance -> VM Actions -> Edit this Button Group

To test this navigate to
Compute -> Infrastructure -> Virtual Machines
Select a VM
Click on the VM Actions and run select the Button from the drop down

This should launch a Job on the Ansible Tower

[dmcknight]

Thank you for the write-up. Everything works up until we try to add the button. When we try to add a button under VM Template and Image Button Group “Unassigned Buttons” the ability to “add new button” is not available and we are only presented with “No Buttons Found.” This is on the beta release of Darga. Is there a way to add the Ansible Tower functionality to the stable version or dig further into our issue? I am new to GitHub and ManageIQ so please forgive any silly questions. Any guidance is appreciated.

Thanks

[mkanoor]

Hello,
This issue was reported in https://github.com/ManageIQ/manageiq/issues/8195
and fixed with PR https://github.com/ManageIQ/manageiq/pull/8197.

If you get the latest build you should see it resolved
Thanks,
Madhu

[cjung]

HiHo,
I was looking at the code of the “Launch” method. Is there a way to check for the result of the executed job? Like return code, potential errors or on how many systems the job was executed?

Regards,
Christian

[mkanoor]

When we execute a job on the tower, it has a job id and the job has the stdout, with all the output from the job template. We don’t parse the stdout that would be left to the individual methods since each template could write output data in different formats.
We have a PR waiting for accessing the stdout https://github.com/ManageIQ/manageiq/pull/8492
so you could do a job.raw_stdout from the Automate method and then parse the contents.

When we launch the ansible job it runs a state machine which first launches the job async and then waits for the job to end in the wait_for_completion method. Once the job ends on the tower with either a failure or success, you can can access the job.raw_stdout and parse the contents.

[dmcknight]

Thank you for the prompt reply, We attempt an update on the vmware darga appliance with:
cd /var/www/miq/vmdb
git pull
bundle install
updates around 233 gems
rake evm:restart

This results in an “unsuable” appliance after a restart even though it states it was restarted.

Is there a different method we should be following to update the appliance.
Thanks

[gmccullough]

@jrafanie Any thoughts on the appliance update they tried here?

[dmcknight]

Got it working with a complete reset of the database, that is fine for the appliance since we are just testing. Thanks for all the input.

[mkanoor]

This topic was updated to reflect the changes made to make the dialog parameters consistent between service and dialogs.

The PR related to this issue is

Consistent parameters for ansible job

The name of any extra variable that needs to be sent to Ansible Tower if coming from a service dialog should be prefixed with param,
e.g. _param_pkg_
the dialog prefix is automatically added by the system. You don’t have to append dialog to the name.

When it gets to the Automate Method it comes in as dialog_param_pkg, the Automate method strips out the prefix dialog_param_ and takes the rest of the string as the Ansible variable name.

[mkanoor]

Pavol Kotvan asked a question
Can you please explain why the Request must be named “Ansible_Tower_Job”?

Response:
Whenever we send an Automate Request it looks for matching instances in the System/Request that match the request name (case insensitive). And whatever needs to be processed will be defined in that object (attributes, relationships, methods).
If you look in ManageIQ domain you will see an instance System/Request/ansible_tower_job the contents of which look like

Which basically calls the JobTemplate state machine to process the Ansible Tower Job.