Problem
The chart exposes alpha.extraInitContainers but no equivalent for long-running sidecar containers on either alpha or zero. There is also no extraVolumes / extraVolumeMounts extension point, which means sidecars cannot reach shared mounts or attach additional volumes to the primary Dgraph container without forking the chart or postrendering.
Motivation
Sidecar containers are the standard Kubernetes pattern for concerns that must live in the same pod as Dgraph but are separately maintained: log forwarders, in-pod proxies (e.g., mTLS-terminating metrics scrapers when client_auth_type: REQUIREANDVERIFY is set and the scraper cannot present a client cert), local auth translators, service-mesh helpers. Today users needing any of these must fork the chart or run Helm postrender scripts, both of which drift or break on chart upgrades.
Established charts (Bitnami's, Grafana's, kube-prometheus-stack, cert-manager, and others) universally expose extraContainers alongside extraInitContainers. This proposal aligns the Dgraph chart with that convention.
Proposed change
Add three symmetric optional values on both alpha and zero:
extraContainers: [] — rendered into the pod spec containers list alongside the primary Dgraph container.extraVolumes: [] — pod-level volumes available to the primary container and any extraContainers.extraVolumeMounts: [] — additional mounts attached to the primary Dgraph container. Sidecars mount their own volumes inside their own container spec.
All three default to empty; the chart behaves identically to today for existing users.
Prior art in this chart
alpha.extraInitContainers (v25.0.0-preview6 values.yaml) establishes the pattern. Naming and rendering convention (tpl (toYaml .) $ | nindent 6) copied verbatim.
PR
Draft PR ready. Small diff (~50 lines across values.yaml, alpha and zero StatefulSet templates), backward-compatible, verified via helm template with a non-empty extraContainers that the sidecar renders correctly and with empty values that the output is byte-identical to the current chart. Happy to iterate on naming or template placement if maintainers prefer a different shape.
Problem
The chart exposes
alpha.extraInitContainersbut no equivalent for long-running sidecar containers on either alpha or zero. There is also noextraVolumes/extraVolumeMountsextension point, which means sidecars cannot reach shared mounts or attach additional volumes to the primary Dgraph container without forking the chart or postrendering.Motivation
Sidecar containers are the standard Kubernetes pattern for concerns that must live in the same pod as Dgraph but are separately maintained: log forwarders, in-pod proxies (e.g., mTLS-terminating metrics scrapers when
client_auth_type: REQUIREANDVERIFYis set and the scraper cannot present a client cert), local auth translators, service-mesh helpers. Today users needing any of these must fork the chart or run Helm postrender scripts, both of which drift or break on chart upgrades.Established charts (Bitnami's, Grafana's, kube-prometheus-stack, cert-manager, and others) universally expose
extraContainersalongsideextraInitContainers. This proposal aligns the Dgraph chart with that convention.Proposed change
Add three symmetric optional values on both
alphaandzero:extraContainers: []— rendered into the pod speccontainerslist alongside the primary Dgraph container.extraVolumes: []— pod-level volumes available to the primary container and anyextraContainers.extraVolumeMounts: []— additional mounts attached to the primary Dgraph container. Sidecars mount their own volumes inside their own container spec.All three default to empty; the chart behaves identically to today for existing users.
Prior art in this chart
alpha.extraInitContainers(v25.0.0-preview6 values.yaml) establishes the pattern. Naming and rendering convention (tpl (toYaml .) $ | nindent 6) copied verbatim.PR
Draft PR ready. Small diff (~50 lines across
values.yaml, alpha and zero StatefulSet templates), backward-compatible, verified viahelm templatewith a non-emptyextraContainersthat the sidecar renders correctly and with empty values that the output is byte-identical to the current chart. Happy to iterate on naming or template placement if maintainers prefer a different shape.