In a Helm Chart.yaml dependency, what does the condition field do, and what happens if its values path is absent?

### Where the field lives A chart declares what it bundles in `Chart.yaml`, under `dependencies`. Each entry has a `name`, a `version` range and a `repository`, and may add `alias`, `tags`, `import-values` and `condition`. `condition` is the on/off switch for that one dependency: ```yaml apiVersion: v2 name: billing version: 4.2.1 dependencies: - name: postgresql version: 15.3.2 repository: https://charts.example.internal condition: postgresql.enabled ``` The string is a **values path**, written with dots, addressed from the top of the values tree the release is rendered with. It is not a template expression - there is no `{{ }}`, no function, no comparison. It can only point at something that is already a boolean. ### How Helm resolves it Before any template is executed, Helm walks the dependency list and computes an `enabled` flag for every entry. Everything starts enabled. For an entry with a condition, Helm splits the string on commas and tries each path in order: - the first path that resolves to a boolean wins, and evaluation stops there; - a path that does not exist in the values is skipped, and the next path is tried; - a path that exists but holds something else - the *string* `"false"`, a number, a map - is not usable, and Helm logs a warning and moves on; - if no path yields a boolean, the condition contributes nothing and the dependency keeps whatever state it already had. Two consequences bite people. First, resolution is **silent on failure**: a typo such as `postgresql.enable` is simply a path that does not exist, so the subchart renders and no error is printed. Second, YAML types matter: `postgresql.enabled: "false"` is a quoted string, not a boolean, and it will not disable anything. `--set postgresql.enabled=false` produces a real boolean; `--set-string` would not. The comma-separated form exists so a chart can honour more than one switch, for example a specific key and a shared fallback: `condition: postgresql.enabled,global.bundledDatabase`. The first of those that actually exists in the caller's values decides, so a specific per-chart key overrides a broad one only because it is listed first. ### What "disabled" actually means A disabled dependency is **not rendered**. None of its templates execute, so none of its objects appear in the manifest Helm applies and stores with the revision, and none of its hook manifests exist to be run. Its `NOTES.txt` contributes nothing. From the cluster's point of view the subchart may as well not be in the chart. What does *not* change is packaging. The entry is still in `Chart.yaml`, still pinned in `Chart.lock`, still vendored as a `.tgz` under `charts/`, and still inside the parent's packaged archive. Enablement is a render-time decision taken from values; it is not a way to slim down a chart or to avoid fetching a dependency. ### Why charts are built this way The pattern exists so one chart can serve two shapes of deployment. A team ships a chart for a subscription-billing service that bundles a database subchart so a developer can `helm install` it on a laptop and get something that works. In production the same chart runs against a managed database, and the platform team passes `postgresql.enabled=false` plus an external host in a values file. There is one chart, one version stream, and no fork - the difference between the environments is data, reviewed in a values file, not a divergent copy of the templates. Chart authors therefore give the switch a default in the parent's own `values.yaml` (usually `enabled: true`, so the out-of-the-box install works) and document the key. Consumers flip it per environment. ### Checking it Because the failure mode is silence, verify rather than assume. Rendering locally with the exact values you intend to use shows precisely which objects the chart will produce, and grepping that output for the subchart's resources answers the question directly - before anything reaches a cluster.