📋 Prerequisites
📝 Feature Summary
Add openai.secretRef to the querydoc sub-chart so operators can point it at a pre-existing Secret instead of having to put the API key into Helm values.
❓ Problem Statement / Motivation
The querydoc sub-chart only accepts an inline openai.apiKey value. There is no way to bind the deployment's envFrom to a Secret managed outside the chart (External Secrets, sealed-secrets, manual kubectl create secret, etc.).
This forces operators who keep secrets out of Git to use awkward workarounds — e.g. setting openai.apiKey: "placeholder", overwriting the rendered Secret manually, and adding ignoreDifferences on /data in ArgoCD so selfHeal doesn't revert the real key. It's bothering.
The sibling grafana-mcp sub-chart already solves this cleanly via grafana.secretRef. It's better that the querydoc follows the same pattern.
💡 Proposed Solution
Mirror the grafana-mcp pattern in helm/tools/querydoc:
values.yaml
- add commented
# secretRef: "" under openai.
templates/secret.yaml
- guard with
{{- if and .Values.openai.apiKey (not .Values.openai.secretRef) }} so the chart skips rendering its own Secret when the user supplies one.
templates/deployment.yaml
envFrom: render secretRef when either apiKey or secretRef is set; resolve the name as {{ .Values.openai.secretRef | default (include "querydoc.fullname" .) | quote }}.
checksum/secret annotation: only meaningful when the chart owns the Secret — tighten the guard accordingly.
Precedence:
apiKey |
secretRef |
Result |
| set |
unset |
chart renders Secret (current behavior) |
| unset |
set |
no Secret rendered; user Secret used |
| set |
set |
secretRef wins (matches grafana-mcp) |
| unset |
unset |
no Secret rendered (current behavior) |
Also propagate the new value through helm/kagent/values.yaml (commented # secretRef: "" under querydoc.openai).
🔄 Alternatives Considered
No response
🎯 Affected Service(s)
None
📚 Additional Context
No response
🙋 Are you willing to contribute?
📋 Prerequisites
📝 Feature Summary
Add
openai.secretRefto thequerydocsub-chart so operators can point it at a pre-existing Secret instead of having to put the API key into Helm values.❓ Problem Statement / Motivation
The
querydocsub-chart only accepts an inlineopenai.apiKeyvalue. There is no way to bind the deployment'senvFromto a Secret managed outside the chart (External Secrets, sealed-secrets, manualkubectl create secret, etc.).This forces operators who keep secrets out of Git to use awkward workarounds — e.g. setting
openai.apiKey: "placeholder", overwriting the rendered Secret manually, and addingignoreDifferenceson/datain ArgoCD soselfHealdoesn't revert the real key. It's bothering.The sibling
grafana-mcpsub-chart already solves this cleanly viagrafana.secretRef. It's better that the querydoc follows the same pattern.💡 Proposed Solution
Mirror the
grafana-mcppattern inhelm/tools/querydoc:values.yaml# secretRef: ""underopenai.templates/secret.yaml{{- if and .Values.openai.apiKey (not .Values.openai.secretRef) }}so the chart skips rendering its own Secret when the user supplies one.templates/deployment.yamlenvFrom: rendersecretRefwhen eitherapiKeyorsecretRefis set; resolve the name as{{ .Values.openai.secretRef | default (include "querydoc.fullname" .) | quote }}.checksum/secretannotation: only meaningful when the chart owns the Secret — tighten the guard accordingly.Precedence:
apiKeysecretRefsecretRefwins (matches grafana-mcp)Also propagate the new value through
helm/kagent/values.yaml(commented# secretRef: ""underquerydoc.openai).🔄 Alternatives Considered
No response
🎯 Affected Service(s)
None
📚 Additional Context
No response
🙋 Are you willing to contribute?