diff options
| author | Jeff Bradberry <jeff.bradberry@gmail.com> | 2021-04-21 21:26:21 +0200 |
|---|---|---|
| committer | Jeff Bradberry <jeff.bradberry@gmail.com> | 2021-04-22 16:20:11 +0200 |
| commit | 65cee65faddaadc38d00e82cb3b0b5f5f9a65608 (patch) | |
| tree | d9f18cd4ceec3ba3cf2ade14f29b695f9e484b69 /docs/tasks.md | |
| parent | Remove isolated nodes from the API views and serializers (diff) | |
| download | awx-65cee65faddaadc38d00e82cb3b0b5f5f9a65608.tar.xz awx-65cee65faddaadc38d00e82cb3b0b5f5f9a65608.zip | |
Update the docs to remove references to isolated nodes
Diffstat (limited to 'docs/tasks.md')
| -rw-r--r-- | docs/tasks.md | 11 |
1 files changed, 0 insertions, 11 deletions
diff --git a/docs/tasks.md b/docs/tasks.md index f2e29ec777..7ff5847052 100644 --- a/docs/tasks.md +++ b/docs/tasks.md @@ -157,17 +157,6 @@ One of the most important tasks in a clustered AWX installation is the periodic If a node in an AWX cluster discovers that one of its peers has not updated its heartbeat within a certain grace period, it is assumed to be offline, and its capacity is set to zero to avoid scheduling new tasks on that node. Additionally, jobs allegedly running or scheduled to run on that node are assumed to be lost, and "reaped", or marked as failed. -#### Isolated Tasks and Their Heartbeats - -AWX reports as much status as it can via the browsable API at `/api/v2/ping` in order to provide validation of the health of an instance, including the timestamps of the last heartbeat. Since isolated nodes don't have access to the AWX database, their heartbeats are performed by controller nodes instead. A periodic task, `awx_isolated_heartbeat`, is responsible for periodically connecting from a controller to each isolated node and retrieving its capacity (via SSH). - -When a job is scheduled to run on an isolated instance, the controller instance puts together the metadata required to run the job and then transfers it to the isolated instance. Once the metadata has been synchronized to the isolated host, the controller instance starts a process on the isolated instance, which consumes the metadata and starts running `ansible/ansible-playbook`. As the playbook runs, job artifacts (such as `stdout` and job events) are written to disk on the isolated instance. - -Alternatively: "While the job runs on the isolated instance, the controller instance periodically checks for and copies the job artifacts (_e.g._, `stdout` and job events) that it produces. It processes these until the job finishes running." - -To read more about Isolated Instances, refer to the [Isolated Instance Groups](https://docs.ansible.com/ansible-tower/latest/html/administration/clustering.html#isolated-instance-groups) section of the Clustering page in the Ansible Tower Administration guide. - - ## AWX Jobs ### Unified Jobs |