shaba/awx
1
0
Fork 0
mirror of https://github.com/ansible/awx.git synced 2024-10-26 16:25:06 +03:00
Code Releases Activity
cbd9dce940
awx/docs/ansible_runner_integration.md
Alan Rominger c59bbdecdb
Refactor canceling to work through messaging and signals, not database 
If canceled attempted before, still allow attempting another cancel
in this case, attempt to send the sigterm signal again.
Keep clicking, you might help!

Replace other cancel_callbacks with sigterm watcher
  adapt special inventory mechanism for this too

Get rid of the cancel_watcher method with exception in main thread

Handle academic case of sigterm race condition

Process cancelation as control signal

Fully connect cancel method and run_dispatcher to control

Never transition workflows directly to canceled, add logs
2022-09-01 15:20:31 -04:00

2.2 KiB
Raw Blame History

Ansible Runner Integration Overview

Much of the code in AWX around ansible and ansible-playbook invocation has been removed and put into the project ansible-runner. AWX now calls out to ansible-runner to invoke ansible and ansible-playbook.

Lifecycle

In AWX, a task of a certain job type is kicked off (i.e., RunJob, RunProjectUpdate, RunInventoryUpdate, etc.) in awx/main/tasks/jobs.py. A temp directory is built to house ansible-runner parameters (i.e., envvars, cmdline, extravars, etc.). The temp directory is filled with the various concepts in AWX (i.e., ssh keys, extra vars, etc.). The code then builds a set of parameters to be passed to the ansible-runner Python module interface, ansible-runner.interface.run(). This is where AWX passes control to ansible-runner. Feedback is gathered by AWX via callbacks and handlers passed in.

The callbacks and handlers are:

  • event_handler: Called each time a new event is created in ansible-runner. AWX will dispatch the event to redis to be processed on the other end by the callback receiver.
  • cancel_callback: Called periodically by ansible-runner; this is so that AWX can inform ansible-runner if the job should be canceled or not. Only applies for system jobs now, and other jobs are canceled via receptor.
  • finished_callback: Called once by ansible-runner to denote that the process that was asked to run is finished. AWX will construct the special control event, EOF, with the associated total number of events that it observed.
  • status_handler: Called by ansible-runner as the process transitions state internally. AWX uses the starting status to know that ansible-runner has made all of its decisions around the process that it will launch. AWX gathers and associates these decisions with the Job for historical observation.

Debugging

If you want to debug ansible-runner, then set AWX_CLEANUP_PATHS=False, run a job, observe the job's AWX_PRIVATE_DATA_DIR property, and go the node where the job was executed and inspect that directory.

If you want to debug the process that ansible-runner invoked (i.e., Ansible or ansible-playbook), then observe the Job's job_env, job_cwd, and job_args parameters.