Problem
A block-node --values file that defines plugins.names is silently ignored on an interactive install — the deployed plugin list comes from the TUI preset (default tier1-lfh) instead of the operator's values file. helm get values <release> -n <ns> -a and inspecting the container both confirm the values-file list never takes effect, while other overrides in the same file (resources, blockNode.config) do apply.
Operators reasonably expect a --values file to behave like any Helm -f override: if it sets plugins.names, that should win over the chart's built-in default.
Root cause is two-fold:
- The TUI plugin-preset prompt always pre-selects a preset before showing the menu, so the resolved plugin list is essentially never empty on an interactive install (
internal/ui/prompt/blocknode.go, RunPluginPresetPrompts).
injectPluginsConfig then unconditionally overwrites plugins.names whenever the resolved list is non-empty, after the values merge (internal/blocknode/values.go). There is no way to tell the TUI "don't override; use my values file."
PR #703 (deep-merge custom --values over the embedded profile base) is a prerequisite — it makes a values-file plugins.names survive the merge over the chart default — but it does not change the injection/TUI behavior, so the TUI/flags still clobber the values file unconditionally.
Proposed fix
Implement the precedence flags/TUI > values.yaml > chart default for the plugin list. The mechanism is largely already present: when the resolved plugin list is empty, injectPluginsConfig is a no-op and PR #703's merge yields the values-file plugins (or the chart default when the file is silent). The work is to produce an empty resolved list when the operator did not explicitly choose plugins:
- Add an explicit "use values file / chart default (no override)" option to the TUI preset prompt that resolves to an empty plugin list.
- Smart default: when
--values is supplied and defines plugins.names, default the prompt to that "no override" option so the values file wins unless the operator actively picks a preset.
- CLI flags (
--plugins / --plugin-preset) continue to win via the existing cmd.Flag(...).Changed checks.
- Guard the
upgrade path's re-resolution from saved state so it does not clobber a values file that defines plugins (while still handling the chart-version plugin rename for operators who don't manage plugins via values).
Out of scope (track separately): free-form comma-separated plugin entry in the interactive TUI for plugins not offered in the multi-select. Arbitrary plugins remain achievable via --values or --plugins.
This should be stacked on PR #703.
Acceptance
Problem
A block-node
--valuesfile that definesplugins.namesis silently ignored on an interactive install — the deployed plugin list comes from the TUI preset (defaulttier1-lfh) instead of the operator's values file.helm get values <release> -n <ns> -aand inspecting the container both confirm the values-file list never takes effect, while other overrides in the same file (resources,blockNode.config) do apply.Operators reasonably expect a
--valuesfile to behave like any Helm-foverride: if it setsplugins.names, that should win over the chart's built-in default.Root cause is two-fold:
internal/ui/prompt/blocknode.go,RunPluginPresetPrompts).injectPluginsConfigthen unconditionally overwritesplugins.nameswhenever the resolved list is non-empty, after the values merge (internal/blocknode/values.go). There is no way to tell the TUI "don't override; use my values file."PR #703 (deep-merge custom
--valuesover the embedded profile base) is a prerequisite — it makes a values-fileplugins.namessurvive the merge over the chart default — but it does not change the injection/TUI behavior, so the TUI/flags still clobber the values file unconditionally.Proposed fix
Implement the precedence flags/TUI >
values.yaml> chart default for the plugin list. The mechanism is largely already present: when the resolved plugin list is empty,injectPluginsConfigis a no-op and PR #703's merge yields the values-file plugins (or the chart default when the file is silent). The work is to produce an empty resolved list when the operator did not explicitly choose plugins:--valuesis supplied and definesplugins.names, default the prompt to that "no override" option so the values file wins unless the operator actively picks a preset.--plugins/--plugin-preset) continue to win via the existingcmd.Flag(...).Changedchecks.upgradepath's re-resolution from saved state so it does not clobber a values file that defines plugins (while still handling the chart-version plugin rename for operators who don't manage plugins via values).Out of scope (track separately): free-form comma-separated plugin entry in the interactive TUI for plugins not offered in the multi-select. Arbitrary plugins remain achievable via
--valuesor--plugins.This should be stacked on PR #703.
Acceptance
--valuesdefiningplugins.namesdeploys that list;helm get values -ashows the values-file plugins, not the preset default.--plugin-preset/--pluginsstill override a values-fileplugins.names(flags win).plugins.namesin the values file, the chart default is used.reconfigure(prompts skipped, no flags) honors a values-fileplugins.names.upgradedoes not overwrite a values-fileplugins.names, while the chart-version plugin rename still applies when plugins are not managed via values.