Open labmonkey42 opened 1 month ago
Thanks for migrating the issue to this repo @labmonkey42
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
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
featuredisabled
automatically (and transparently) change podresources
to setlimits
equal to therequests
value when both values are defined. This means thatawx-operator-controller-manager
is left with insufficient memory, and will always beOOMKilled
.In my case, I deploy the
awx-operator
helm chart with an Ansible playbook, and thus I can use akubernetes.core.k8s_json_patch
task on theDeployment
to set therequests
value equal to thelimits
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
andlimits
for theawx-manager
pod in theDeployment
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
.