Chart bypasses image entrypoint and lacks per-component extraEnv, making INFLUXDB3_UNSET_VARS (and similar overrides) unreachable

[jvargasapo]

Description
I believe there are two related gaps in the chart that together make a useful image feature unreachable via the values file. I'm not 100% certain, but I'll share what I observed and what seems to cause the behavior.

What I expected
The Docker image (docker.io/influxdb:3-enterprise) ships with an entrypoint script at /usr/bin/entrypoint.sh that supports unsetting env vars at container startup via INFLUXDB3_UNSET_VARS:

from /usr/bin/entrypoint.sh inside the image
if [[ -n "${INFLUXDB3_UNSET_VARS:-}" ]]; then
    read -ra vars <<< "${INFLUXDB3_UNSET_VARS}"
    for var in "${vars[@]}"; do
        unset "$var" || { echo "Error: Failed to unset variable '$var'"; exit 1; }
    done
fi

I expected to be able to use this from values.yaml, for example to keep INFLUXDB3_PLUGIN_DIR set on the processor but unset on the other components (since the binary auto-enables process mode whenever INFLUXDB3_PLUGIN_DIR is set, which results in every component reporting [ingest, process] / [query, process] / [compact, process] in SHOW NODES even when those components don't need plugin support):

ingester:
  extraEnv:
    - name: INFLUXDB3_UNSET_VARS
      value: "INFLUXDB3_PLUGIN_DIR"

What actually happens
There are two issues that combine:

Issue 1: the chart's command: bypasses the image entrypoint
Looking at templates/ingester-statefulset.yaml (the same pattern appears in querier/compactor/processor templates), the chart sets a custom command: on the container:

command:
  - /bin/sh
  - -c
  - |
    exec influxdb3 \
      serve \
      --mode=ingest \
      --node-id=$(hostname)

I believe this is the root cause for the unset feature being unreachable: when a Kubernetes pod spec sets command:, it overrides the image's ENTRYPOINT. As far as I understand it, this means /usr/bin/entrypoint.sh (and the INFLUXDB3_UNSET_VARS logic) never runs. The env var ends up present in the container, but no code in the running container reads it, the binary itself doesn't implement that feature, only the entrypoint script does.

Issue 2: extraEnv is only exposed at the top level, not per component
Even if Issue 1 were resolved, the chart only honors .Values.extraEnv (top-level). There's no .Values.ingester.extraEnv / .Values.querier.extraEnv / etc.:

$ grep -rn "extraEnv" charts/influxdb3-enterprise/
values.yaml:832            extraEnv: []
templates/querier-statefulset.yaml:98       {{- with .Values.extraEnv }}
templates/ingester-statefulset.yaml:120     {{- with .Values.extraEnv }}
templates/compactor-statefulset.yaml:129    {{- with .Values.extraEnv }}
templates/processor-statefulset.yaml:147    {{- with .Values.extraEnv }}

This means any env var override applies to all four components at once, including the processor. So even if INFLUXDB3_UNSET_VARS could be read, you couldn't use it to selectively suppress process mode on ingester/querier/compactor while keeping plugin functionality on the processor, you'd unset INFLUXDB3_PLUGIN_DIR everywhere or nowhere.

I tested setting extraEnv: INFLUXDB3_PLUGIN_DIR="" at the top level just to confirm the scope, and it crashed ingester/querier/compactor with error: a value is required for '--plugin-dir <PLUGIN_DIR>' but none was supplied, while the processor stayed running (it has its own hardcoded INFLUXDB3_PLUGIN_DIR=/plugins in its template that overrode our extraEnv). This isn't a usable solution, but it does confirm both that the chart applies extraEnv globally and that empty-string overrides don't work as a workaround.

I can't say with certainty whether either behavior is intentional, but the practical effect is that the image's documented unset feature can't be reached through the chart, and even if it could, it would only be controllable cluster-wide.

Suggested options
Two complementary changes that together would close the gap:

Let the image entrypoint run. Either call it explicitly:

command:

  - /usr/bin/entrypoint.sh
  - /bin/sh
  - -c
  - "exec influxdb3 serve --mode=ingest --node-id=$(hostname)"

Or use args: instead of command: and let the image's default ENTRYPOINT run.

Add per-component extraEnv support. Allow setting env vars under each component, e.g.:

ingester:
  extraEnv:
    - name: INFLUXDB3_UNSET_VARS
      value: "INFLUXDB3_PLUGIN_DIR"

The templates would then need to merge per-component env with the top-level extraEnv.

With both changes, users would be able to selectively control behavior per component using the image's built-in mechanisms.

Environment
Chart: influxdata/influxdb3-enterprise (version 0.4.0)
App version: 3.9.2
Image: docker.io/influxdb:3-enterprise
Kubernetes: EKS 1.32
Happy to provide reproduction steps or test changes if helpful.

[alespour]

PR #799 ready for review