What happens
packages/apps/clickhouse/templates/chkeeper.yaml:61 sizes the ClickHouse Keeper container by passing the ClickHouse server's resources as the override:
resources: {{- include "cozy-lib.resources.defaultingSanitize" (list .Values.clickhouseKeeper.resourcesPreset .Values.resources $) | nindent 20 }}
defaultingSanitize merges the preset with the explicit resources and lets the explicit values win. So on any release that sets top-level resources: (the server's CPU/memory), the Keeper silently inherits that sizing and clickhouseKeeper.resourcesPreset is ignored — the value the user set to size the Keeper has no effect.
There is also no way to express the intent instead: clickhouseKeeper exposes only enabled, replicas, resourcesPreset and size — there is no clickhouseKeeper.resources.
Why it matters
Keeper is a coordination service with a very different resource profile from the server. A release that gives the server, say, 8 CPU / 32Gi gets three Keeper replicas asking for the same, which at best wastes reservation and at worst makes the Keeper Pods unschedulable — and the resourcesPreset: t1.micro default that was supposed to prevent exactly that is bypassed. It is misconfiguration rather than breakage, which is why it has gone unnoticed.
Suggested fix
Either pass an empty override so the preset actually governs the Keeper, or (better) add a clickhouseKeeper.resources value and pass that:
resources: {{- include "cozy-lib.resources.defaultingSanitize" (list .Values.clickhouseKeeper.resourcesPreset .Values.clickhouseKeeper.resources $) | nindent 20 }}
The second form is the behaviour-preserving one for anyone who has not set top-level resources:, and it makes the Keeper independently sizeable. Note it changes effective sizing for releases that currently set top-level resources:, so it likely wants a release note.
While in there: line 61 also carries trailing whitespace.
Provenance
Present since 896209a (2025-08-07). Found during review of #3385, which touches this chart but not this line — the new e2e fixture happens to sidestep it by setting resources: {}. Filing rather than fixing in that PR to keep an unrelated sizing change out of a backup/e2e PR.
What happens
packages/apps/clickhouse/templates/chkeeper.yaml:61sizes the ClickHouse Keeper container by passing the ClickHouse server's resources as the override:defaultingSanitizemerges the preset with the explicit resources and lets the explicit values win. So on any release that sets top-levelresources:(the server's CPU/memory), the Keeper silently inherits that sizing andclickhouseKeeper.resourcesPresetis ignored — the value the user set to size the Keeper has no effect.There is also no way to express the intent instead:
clickhouseKeeperexposes onlyenabled,replicas,resourcesPresetandsize— there is noclickhouseKeeper.resources.Why it matters
Keeper is a coordination service with a very different resource profile from the server. A release that gives the server, say, 8 CPU / 32Gi gets three Keeper replicas asking for the same, which at best wastes reservation and at worst makes the Keeper Pods unschedulable — and the
resourcesPreset: t1.microdefault that was supposed to prevent exactly that is bypassed. It is misconfiguration rather than breakage, which is why it has gone unnoticed.Suggested fix
Either pass an empty override so the preset actually governs the Keeper, or (better) add a
clickhouseKeeper.resourcesvalue and pass that:The second form is the behaviour-preserving one for anyone who has not set top-level
resources:, and it makes the Keeper independently sizeable. Note it changes effective sizing for releases that currently set top-levelresources:, so it likely wants a release note.While in there: line 61 also carries trailing whitespace.
Provenance
Present since 896209a (2025-08-07). Found during review of #3385, which touches this chart but not this line — the new e2e fixture happens to sidestep it by setting
resources: {}. Filing rather than fixing in that PR to keep an unrelated sizing change out of a backup/e2e PR.