ansible-community / awx-operator-helm

Helm chart for the AWX operator.
https://ansible-community.github.io/awx-operator-helm/
GNU General Public License v3.0
25 stars 8 forks source link

Expose resources for awx-controller-manager in chart #14

Open labmonkey42 opened 1 month ago

labmonkey42 commented 1 month ago

Migrating from https://github.com/ansible/awx-operator/issues/1919

Summary

As noted in https://github.com/ansible/awx-operator/issues/1115, GKE Autopilot automatically changes pod resource requests and/or limits. The specific defect described in that issue occurs because Autopilot clusters with the bursting feature disabled automatically (and transparently) change pod resources to set limits equal to the requests value when both values are defined. This means that awx-operator-controller-manager is left with insufficient memory, and will always be OOMKilled.

In my case, I deploy the awx-operator helm chart with an Ansible playbook, and thus I can use a kubernetes.core.k8s_json_patch task on the Deployment to set the requests value equal to the limits value immediately after the helm chart is deployed, effectively working around the problem. However, this does introduce the issue that any change that redeploys the chart will also have to re-patch the Deployment.

What https://github.com/ansible/awx-operator/issues/1115 didn't spell out, and I'm specifically requesting here, is the ability to adjust the resources requests and limits for the awx-manager pod in the Deployment from the helm chart values directly. This would allow us to handle this issue before deploying the chart, and prevent the play from repeatedly adjusting these values in subsequent runs.

Basically, as D1StrX notes there, the CRD AWX should include a section for awx_manager_resource_requirements.

oraNod commented 1 month ago

Thanks for migrating the issue to this repo @labmonkey42

miles-w-3 commented 1 month ago

I believe it is possible to do this by writing the deployment code to a tpl file, and then parsing from a macro before it lands on the cluster. This will allow the use of helm values to modify the kustomize output for the controller deployment, as opposed to how it is currently used now, which is simply just to create manifests