[Question]: Is the omission of env support for the operator Deployment intentional?

[hjchoi0330]

All components in the chart (validator, driver, toolkit, devicePlugin, dcgm, gfd, migManager, etc.) support custom env injection via values.yaml, and these are rendered in clusterpolicy.yaml. However, the operator Deployment in templates/operator.yaml only has three hardcoded env vars (WATCH_NAMESPACE, OPERATOR_NAMESPACE, DRIVER_MANAGER_IMAGE) and does not support additional env injection through values.

Is this an intentional design decision to restrict the operator container's environment, or would a PR adding operator.env support be welcome?

[rahulait]

Thanks @hjchoi0330 for bringing this up. What additional env vars are you planning to inject and how do you plan to use them? We are fine with contributions, so please feel free to open a PR with details on how it would be useful for others and we can get that in.

[github-actions]

This issue is stale because it has been open 90 days with no activity. This issue will be closed in 30 days unless new comments are made or the stale label is removed. To skip these checks, apply the "lifecycle/frozen" label.

[kvnloo]

I rechecked this against current main and it looks like this functionality exists now.

deployments/gpu-operator/templates/operator.yaml contains:

{{- if .Values.operator.env }}

followed by rendering of:

.Values.operator.env

into the operator container's env: list.

So the original omission appears to have been addressed since this issue was opened.

Unless there is a remaining chart/schema/documentation gap, I think this issue can probably be closed as implemented.

It may be useful to note the first release containing operator.env so users on older chart versions know whether they need to upgrade.