Yan Bondarenko 59e1352d85 fix(backups): give the barman-cloud sidecar its own resources ...

The barman-cloud plugin injects its sidecar without resource requests or
limits. Tenant namespaces ship a LimitRange that defaults containers to
128Mi, so the sidecar inherits that default and is OOMKilled mid-backup:
the ObjectStore stays healthy, the Cluster stays Ready, and only the
backup fails. A cgroup high-water mark of 254 MiB on a 38 MB database
shows the default cannot hold it.

The shared cozy-lib helper and the Go path that builds the platform's own
ObjectStore now request 100m/256Mi and cap memory at 1Gi. No CPU limit is
set, matching the entityOperator precedent in the kafka chart: a
throttled sidecar stalls WAL archiving instead of failing it.

The helper is renamed from checksumSidecarConfiguration to
sidecarConfiguration, since it no longer carries only the checksum pin.

Signed-off-by: Yan Bondarenko <202671653+yankawai@users.noreply.github.com>
(cherry picked from commit 9214430bd8)

2026-09-18 18:45:00 +00:00

..

deepcopy_test.go

fix(backups): give the barman-cloud sidecar its own resources

2026-09-18 18:45:00 +00:00

types.go

fix(backups): give the barman-cloud sidecar its own resources

2026-09-18 18:45:00 +00:00

zz_generated.deepcopy.go

fix(backups): give the barman-cloud sidecar its own resources

2026-09-18 18:45:00 +00:00