# Job Slicing AWX Operator

**URL:** <https://forum.ansible.com/t/job-slicing-awx-operator/5247>\
**Category:** Project Discussions\
**Tags:** awx-operator, awx, kubernetes\
**Created:** [May 1, 2024, 10:04pm UTC](https://forum.ansible.com/t/job-slicing-awx-operator/5247 "2024-05-01T22:04:06Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![Denney-tech](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/denney-tech/32/1556_2.png) [@Denney-tech](https://forum.ansible.com/u/Denney-tech)\
**Post date:** [May 2, 2024, 2:20pm UTC](https://forum.ansible.com/t/job-slicing-awx-operator/5247/2 "2024-05-02T14:20:18Z")

</div>

The AWX-Operator only controls how many web/task replicas there are (task replicas are also known as `control nodes` and are members of the `controlplane` Instance Group in AWX). It doesn’t support HPA _yet_, but there’s been some discussions about how to implement it and test such a feature.

Job slicing on the other hand has nothing to do with the operator. When you queue up a job with multiple slices, AWX’s control/execution nodes spawn the automation-job pods (not the operator!) up to the maximum concurrent job count defined for all available Instance Groups (default is unlimited!).

I went over how you can tune that [here](http://forum.ansible.com/t/pod-awx-operator-controller-manager-crashing-and-restarting-nonstop-with-huge-inventory/4620/5).

I don’t know anything about EKS or karpentor, but if the k8s cluster can scale up to handle a high number of automation pods, then I don’t see any reason why you couldn’t take advantage of that. You would just need to make sure AWX’s Instance Groups only spawn a maximum count that coincides with whatever maximum you allow the k8s cluster to scale to.

---

_[View the full topic](https://forum.ansible.com/t/job-slicing-awx-operator/5247)._