skip to content

After `helm upgrade --reuse-values`, a key you deleted from your values file still renders — why?

level: seniorimportance: should knowfreq 46%

answer

  1. A removed line is not a delete
  2. Absence is what the flag fills in
  3. Check the stored overrides, not the render
  4. One command shows supplied, one shows computed
  5. Reset-then-reuse resurrects it too

basics

~20 s

Deleting a key from your file only removes it from what you pass; --reuse-values merges the previous release's stored values underneath, so it comes back. helm get values prints those stored overrides; helm get values -a prints everything computed.

solid answer

~50 s

Removing a line from a values file is not a delete instruction — it is an absence, and absence is exactly what a reuse flag fills in. A recommendation re-ranker chart names the Secret it renders from a fullname helper truncated to 63 characters. The team drops `nameOverride` from `prod-values.yaml` so the Secret will be named after the release, upgrades with `--reuse-values`, and revision 47 renders the same old truncated name. Diagnose it with `helm get values rerank`, which prints only the stored user-supplied map: `nameOverride` is still sitting there, because `--reuse-values` merged the previous revision's values under yours. `helm get values rerank -a` shows the full computed set, chart defaults included, which tells you what the templates saw. `--reset-then-reuse-values` does not help — it also re-applies the old overrides. The fix is to stop reusing and pass the complete file.

code

bash · 14 lines
bash
# The file no longer sets nameOverride, yet the render still uses it
grep -c nameOverride prod-values.yaml

# The stored override map still carries it: this is the culprit
helm get values rerank

# Everything the templates actually resolved against
helm get values rerank -a

# When did it get carried in?
helm get values rerank --revision 46

# The fix: the file is the whole override set again
helm upgrade rerank ./reranker-chart -f prod-values.yaml --reset-values

go deeper

for a junior

Remember that deleting a line from a values file removes it from what you pass, not from the release. If you used a reuse flag, the old value is still stored and will be merged back in.

for a middle

Explain which command prints the stored overrides versus the full computed set, and use the difference between them to say whether a value came from the chart, the file, or the previous revision.

for a senior

Diagnose it end to end: compare the stored override map across revisions, show that reset-then-reuse would not have helped, and pick the fix that leaves the release reproducible from the repository afterwards.

for a principal

Treat this as an evidence problem. Decide how your platform proves that a release matches its checked-in values, so a silently inherited override cannot survive undetected across a team handover.

### The mistake is a category error A values file is not a patch and a removed line is not a deletion. What the file expresses is "here is a set of overrides"; a key that is absent from it is simply not in the set you passed. Every reuse flag exists to fill absences from the previous release, so an absence you created deliberately is indistinguishable from one you never had an opinion about. That is the whole bug. ### The incident, concretely A recommendation re-ranker is installed as release `rerank` from a chart that renders a Secret whose name comes from a fullname helper, truncated to 63 characters so it stays a legal object name. Long ago someone set `nameOverride` to keep the name stable through a rename, so the Secret is called something like `rerank-reranker-inference-sidecar-config-prod-eu-west` cut off at 63 characters. The team now wants the plain release-based name back, so they delete `nameOverride` from `prod-values.yaml`, run `helm upgrade rerank ./reranker-chart -f prod-values.yaml --reuse-values`, and revision 47 comes out with exactly the same Secret name as revision 46. The upgrade succeeded. Nothing warned them. ### The two commands that end the argument `helm get values rerank` prints the release's **user-supplied** values — the override map the revision was created with. Here it still contains `nameOverride`, even though the file on disk does not. That single output proves the value did not come from the chart and did not come from the file: it was inherited. `helm get values rerank -a` prints the **full computed set** — those overrides merged over the chart's `values.yaml` defaults, which is what `.Values` resolved against during the render. Use it to answer "what did the template actually see", and use the plain form to answer "what is being carried in the release record". When the two disagree about a key you care about, the plain form is where the culprit lives. Both accept `--revision <n>`, so diffing the user-supplied map at revision 46 against 47 shows immediately that the key was carried forward rather than introduced. ### Why the sibling flag does not save you It is tempting to reach for `--reset-then-reuse-values` instead. It fixes a different problem — it stops the *old chart's defaults* being carried in — but it still re-applies the previous release's user-supplied overrides, and `nameOverride` is one of those. The key resurfaces just the same. Nothing that reuses the previous overrides can honour a deletion, because a deletion is not represented anywhere in what you passed. ### The fixes, in order of preference 1. **Stop reusing.** Pass the complete file and drop the flag: `helm upgrade rerank ./reranker-chart -f prod-values.yaml`. With no reuse flag and values supplied, the file is the entire override map and the deleted key is genuinely gone. Adding `--reset-values` says the same thing explicitly and reads better in a pipeline. 2. **Be surgical when you cannot reconstruct the file.** Setting the key explicitly to null in the values you pass is the documented way to remove a key rather than override it. It is the right tool for a one-off on a release whose file has been lost, and the wrong tool as a habit, because the next reader has no idea why a null is there. After either fix, re-run `helm get values` and confirm the key is gone from the stored map — not just from the rendered output — or the next person to use a reuse flag will resurrect it. ### What this incident should change A release that can only be reproduced by inheriting from itself has no source of truth. The durable lesson is not "remember which flag deletes": it is that reuse flags convert your values file from a specification into a suggestion. Pipelines that always pass the whole file never meet this bug, because for them a removed line and a removed value are the same thing. Reserve reuse for interactive triage, and treat any reuse flag inside automation as a defect to be argued for rather than assumed.

  • What is the difference between `helm get values` and `helm get values -a` for this diagnosis?
    The plain form prints only the user-supplied override map stored with the revision, so anything appearing there was passed or inherited, never taken from the chart. The `-a` form prints the full computed set with chart defaults merged in, which is what the templates resolved against. You use the plain form to find the culprit and `-a` to explain the rendered output.
  • Would `--reset-then-reuse-values` have prevented the key from coming back?
    No. It only stops the previous chart version's defaults being carried forward; it still re-applies the previous release's user-supplied overrides, and the deleted key is one of those. Any flag that inherits overrides will resurrect it. Only supplying the complete file without a reuse flag, or explicitly nulling the key, removes it.
  • The values file for a legacy release has been lost. How do you get back to a file-driven upgrade safely?
    Capture `helm get values <release>` into a candidate file, then read it against the chart's own defaults and delete every entry that merely restates one — those are usually fossils from earlier reuse runs. Render both the current release and the candidate with a dry run and compare the manifests. When they match, commit the file and upgrade with it and no reuse flag.

saying these in an interview costs you the question

  • Assuming a removed line deletes a value from the release
  • Reaching for --reset-then-reuse-values as the fix
  • Diagnosing only from the rendered manifest, never the stored values
  • Confusing helm get values with helm show values for the chart
  • Editing the live object instead of the release's values
  • Believing a successful upgrade means the intended change applied

context

resolving links…