Yan Bondarenko 9214430bd8 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>

2026-09-18 17:30:20 +04:00

..

deepcopy_test.go

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

2026-09-18 17:30:20 +04:00

types.go

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

2026-09-18 17:30:20 +04:00

zz_generated.deepcopy.go

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

2026-09-18 17:30:20 +04:00