Alexey Masolov fcc1aa56d1 Balance controller node selection during capacity ties (#16417)
* Balance controller node selection during capacity ties

When multiple control-plane instances have equal remaining capacity,
the instance selection algorithm always picks the first instance in
iteration order. This causes burst workloads to concentrate all job
management on a single controller pod while others remain idle.

Add a tie-breaking criterion: when would_be_remaining capacity is
equal, prefer the instance with fewer jobs_running. This distributes
the control overhead (event processing, callbacks, output streaming)
more evenly across available controller pods during burst scenarios.

The change is backwards-compatible: when capacity clearly differs,
the existing "most remaining capacity" logic dominates unchanged.

Signed-off-by: Alexey Masolov <amasolov@redhat.com>
Signed-off-by: Alexey Masolov <alexey.masolov@gmail.com>
Made-with: Cursor

* Track jobs_running on controller node for container-group tasks

Address review feedback: container-group tasks only set controller_node
(execution_node is empty), so the previous consume_capacity call on the
control path never incremented jobs_running. This meant the tie-breaker
could not differentiate between nodes.

Now pass job_impact=True on the control path when the controller is not
also the execution node (avoiding double-counting for hybrid nodes).

Also improve test coverage:
- Fix test case to prove capacity dominates over jobs_running
- Add dedicated tests for container-group controller distribution
- Add test verifying equal-capacity tie-breaking behaviour

Signed-off-by: Alexey Masolov <amasolov@redhat.com>
Signed-off-by: Alexey Masolov <alexey.masolov@gmail.com>
Made-with: Cursor

* Add docstrings to consume_capacity and fit_task_to_most_remaining_capacity_instance

Address CodeRabbit docstring coverage warning by documenting the two
methods modified in this PR. No functional changes.

Signed-off-by: Alexey Masolov <amasolov@redhat.com>
Co-authored-by: Cursor <cursoragent@cursor.com>

---------

Signed-off-by: Alexey Masolov <amasolov@redhat.com>
Signed-off-by: Alexey Masolov <alexey.masolov@gmail.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Liam Allen <lallen@redhat.com>
2026-07-21 15:46:47 +01:00
2026-04-28 16:07:14 -04:00
2024-08-22 13:48:56 -04:00
2026-04-28 16:07:14 -04:00
2017-08-29 21:18:56 -04:00
2017-08-22 14:34:25 -04:00
2026-04-28 16:07:14 -04:00
2025-09-18 09:41:41 -04:00
2022-03-15 13:59:42 +00:00

CI codecov Code of Conduct Apache v2 License AWX on the Ansible Forum Ansible Matrix Ansible Discourse

AWX

Caution

The last release of this repository was released on Jul 2, 2024. Releases of this project are now paused during a large scale refactoring. For more information, follow the Forum and - more specifically - see the various communications on the matter:

AWX provides a web-based user interface, REST API, and task engine built on top of Ansible. It is one of the upstream projects for Red Hat Ansible Automation Platform.

To install AWX, please view the Install guide.

To learn more about using AWX, view the AWX docs site.

The AWX Project Frequently Asked Questions can be found here.

The AWX logos and branding assets are covered by our trademark guidelines.

Contributing

  • Refer to the Contributing guide to get started developing, testing, and building AWX.
  • All code submissions are made through pull requests against the devel branch.
  • All contributors must use git commit --signoff for any commit to be merged and agree that usage of --signoff constitutes agreement with the terms of DCO 1.1
  • Take care to make sure no merge commits are in the submission, and use git rebase vs. git merge for this reason.
  • If submitting a large code change, it's a good idea to join discuss via the Ansible Forum. This helps everyone know what's going on, and it also helps save time and effort if the community decides some changes are needed.

Reporting Issues

If you're experiencing a problem that you feel is a bug in AWX or have ideas for improving AWX, we encourage you to open an issue and share your feedback. But before opening a new issue, we ask that you please take a look at our Issues guide.

Code of Conduct

We require all of our community members and contributors to adhere to the Ansible code of conduct. If you have questions or need assistance, please reach out to our community team at codeofconduct@ansible.com

Get Involved

We welcome your feedback and ideas via the Ansible Forum.

For a full list of all the ways to talk with the Ansible Community, see the AWX Communication guide.

Description
AWX provides a web-based user interface, REST API, and task engine built on top of Ansible. It is one of the upstream projects for Red Hat Ansible Automation Platform.
Readme 425 MiB
Languages
Python 97.9%
Jinja 0.9%
Makefile 0.5%
Shell 0.3%
HTML 0.2%
Other 0.1%