External-Mirrors/awx
2
0
Fork 0
mirror of https://github.com/ansible/awx.git synced 2026-02-01 01:28:09 -03:30
Code Issues Packages Projects Releases Wiki Activity

Update and expand docs/ folder for EEs

Browse Source
This commit is contained in:
Alan Rominger
2021-06-16 11:23:59 -04:00
parent 395af1b5e4
commit 4478052b71
2 changed files with 71 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/clustering.md
View File

@@ -181,13 +181,21 @@ If an Instance Group is configured but all instances in that group are offline o
#### Project Synchronization Behavior
Project updates behave differently than they did before. Previously they were ordinary jobs that ran on a single instance. It's now important that they run successfully on any instance that could potentially run a job. Projects will sync themselves to the correct version on the instance immediately prior to running the job. If the needed revision is already locally checked out and Galaxy or Collections updates are not needed, then a sync may not be performed.
It is important that project updates run on the instance which prepares the ansible-runner private data directory.
This is accomplished by a project sync which is done by the dispatcher control / launch process.
The sync will update the source tree to the correct version on the instance immediately prior to transmitting the job.
If the needed revision is already locally checked out and Galaxy or Collections updates are not needed, then a sync may not be performed.
When the sync happens, it is recorded in the database as a project update with a `launch_type` of "sync" and a `job_type` of "run". Project syncs will not change the status or version of the project; instead, they will update the source tree _only_ on the instance where they run. The only exception to this behavior is when the project is in the "never updated" state (meaning that no project updates of any type have been run), in which case a sync should fill in the project's initial revision and status, and subsequent syncs should not make such changes.
All project updates run with container isolation (like jobs) and volume mount to the persistent projects folder.
#### Controlling Where a Particular Job Runs
By default, a job will be submitted to the `tower` queue, meaning that it can be picked up by any of the workers.
By default, a job will be submitted to the default queue (formerly the `tower` queue).
To see the name of the queue, view the setting `DEFAULT_EXECUTION_QUEUE_NAME`.
Administrative actions, like project updates, will run in the control plane queue.
The name of the control plane queue is surfaced in the setting `DEFAULT_CONTROL_PLANE_QUEUE_NAME`.
##### How to Restrict the Instances a Job Will Run On