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

Redefine execution plane (#10979)

Browse Source
This commit is contained in:
Alan Rominger 2021-08-31 10:33:14 -04:00 committed by GitHub
parent c095f0fc19
commit 573b2bc44f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 2 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
docs/receptor_mesh.md
View File

@ -22,7 +22,7 @@ On the other side, the execution node runs the job under `ansible-runner worker`
### Split of Control Plane versus Execution Plane
Instances in the **control plane** run persistent AWX services (like the web server, task dispatcher, etc.), project updates, and management jobs. Instances in the **execution plane** run user-space jobs.
Instances in the **control plane** run persistent AWX services (like the web server, task dispatcher, etc.), project updates, and management jobs.
The task manager logic will not send user-space jobs to **control-only** nodes.
In the inventory definition, the user can set a flag to designate this node type.
@ -30,6 +30,7 @@ In the inventory definition, the user can set a flag to designate this node type
**Execution-only** nodes have a minimal set of software requirements needed to participate in the receptor mesh and run jobs under ansible-runner with podman isolation.
These _only_ run user-space jobs, and may be geographically separated (with high latency) from the control plane.
They may not even have a direct connection to the cluster, and use other receptor **hop** nodes to communicate.
The hop and execution-only nodes may be referred to collectively as the **execution plane**.
**Hybrid** (control & execution nodes) are instances in the control plane that are allowed to run user-space jobs.