Overview
AWX uses the dispatcherd library for all task management. This is a dedicated task queue system that distributes work across machines in an AWX installation.Key Components
Dispatcherd Library
AWX uses the dispatcherd library for task management:- Repository: https://github.com/ansible/dispatcherd
- Purpose: Separate library for task queue functionality
- Integration: Direct usage in AWX
Task Decorator
Tasks are decorated using:Task Queues and Workers
Task Queue Abstraction
AWX uses a Task Queue abstraction to distribute work: Input: Unit of work called a Task Workers: Dedicated processes on every AWX node that monitor queues Communication: Via distributed queues using PostgreSQL’s pg_notifyClustered Installations
Clustered AWX installations consist of:- Multiple workers spread across every node
- High availability
- Horizontal scaling
Message Types
Direct Messages
Bound directly to a specific named queue. Example: Launching a Job Template- AWX looks at available capacity
- Chooses an Execution Node
- Publishes message to node-specific queue
- Dispatcher on that node listens for events
- Targeted to specific node
- Consumed by one worker process
- Used for job execution, inventory updates, etc.
Shared Direct Queues
Some direct queues are bound by every AWX node. Example: Inventory deletion task- Any available node may perform the work
- First available worker processes the task
Fanout Messages
Sent out in a broadcast fashion. Example: Changing a setting in AWX API- Message broadcast to every AWX node
- Code runs on every node
- Used for cache invalidation, configuration updates
- Broadcast to all nodes
- Every node processes the message
- Ensures cluster-wide consistency
Defining Tasks
Function-Based Tasks
Simple functions decorated with@task():
Class-Based Tasks
Classes with arun() method:
Task Location
Tasks are defined inawx.main.tasks module:
Running Tasks
Publishing Tasks
To run a task in the background:Message Format
When you runapply_async(), a JSON message is composed:
Task Execution
When a worker receives the message:- Deserialize: Parse JSON message
- Import: Import the task callable
- Execute: Run the Python code
- Return: Task completes, result may be stored
Dispatcher Implementation
The Dispatcher Process
Every node runsawx-manage dispatcherd:
- Uses
kombulibrary for message consumption - Consumes from appropriate queues for the node:
- Default shared queue
- Node-specific queue (by hostname)
- Broadcast queue
- Manages pool of child processes
- Distributes inbound messages to workers
Worker Pool
The dispatcher manages a pool of child processes:- Minimum workers: 4 (default)
- Maximum workers: 60 (default)
- Auto-scales based on load
Task Resolution
The dispatcher resolves tasks by dotted path:Running Tasks
Workers execute tasks viarun_callable():
Dispatcher Control
dispatcherctl Command
Theawx-manage dispatcherctl command provides debugging capabilities:
Check Status
- Worker PIDs
- Tasks sent to each worker
- Tasks completed
- Queue size per worker
- Memory usage (RSS)
- Currently running tasks with UUIDs
List Running Tasks
main_unifiedjob.celery_task_id in database).
Task Categories
Housekeeping Tasks
Background maintenance and scheduling:- run_task_manager: Periodic task that schedules jobs
- run_dependency_manager: Creates job dependencies
- run_workflow_manager: Manages workflow execution
Heartbeats and Capacity
Periodic tasks running on every node:- Record node heartbeat
- Calculate and report capacity
- Reap jobs from dead nodes
Job Execution Tasks
Run Ansible playbooks and commands:Administrative Tasks
Maintenance and cleanup:Notification Tasks
Send notifications:Callback Receiver
Special dispatcher process for handling Ansible callback events:- Receive Ansible events from running jobs
- Process event data
- Save to database for UI display
Task Routing
Queue Selection
Tasks can be routed to specific queues:Execution Node Selection
For job execution:- Task Manager selects execution node
- Considers capacity and instance groups
- Routes task to node-specific queue
- Dispatcher on that node processes task
Monitoring and Debugging
Check Dispatcher Health
Task Tracking
Tasks have UUIDs that can be tracked:Common Issues
Dispatcher not running:Performance Tuning
Worker Pool Size
- More workers = more concurrency
- Each worker consumes memory
- Balance based on workload and resources
Queue Backlog
Monitor queue depth:Task Prioritization
Currently AWX uses FIFO (First In, First Out) for task processing. Future enhancements may include:- Priority queues
- Task preemption
- Resource-based scheduling
Security Considerations
Task Validation
Only tasks starting withawx. are allowed:
Credential Handling
Credentials are never passed in task arguments:- Retrieved from database within task
- Decrypted at runtime
- Never logged
Process Isolation
Worker processes are isolated:- Separate process per task
- Failures don’t affect other tasks
- Resource limits via cgroups (in containers)