Alexey Artamonov e54d728087 fix(postgres): stop an unready ScaledObject from wedging the release ...

A Postgres app with autoscaling.enabled but no resolvable metrics endpoint (a
monitoring: true tenant who did not point serverAddress at a vmselect carrying
kube_pod_labels) renders a ScaledObject that stays Ready=False reason=TriggerError
forever. helm-controller's default wait gates the whole HelmRelease on every
rendered resource's kstatus, so that one unready ScaledObject drives the release to
UpgradeFailed and it retries forever - wedging an otherwise-healthy database and
blocking every later chart change to it, while the tenant cannot even read the
ScaledObject to see why (observed on dev3).

Autoscaling health is a degraded-but-alive state surfaced by the DatabaseAutoscaler*
alerts, not a release-readiness gate. Add a spec.release.healthCheckExprs entry on
the postgres ApplicationDefinition that treats the ScaledObject as always-ready for
release readiness (current: "true"); the CNPG Cluster and every other resource keep
their built-in kstatus wait, so the database's own health still gates the release.
Setting any healthCheckExprs couples WaitStrategy to poller
(config.ResolveWaitStrategy); that the poller wait stays equivalent to the default
for the kstatus-checked Cluster is verified on cozystack-pr-test, not here
(render-blind). The cozyrd unittest pins the expr so a regeneration cannot drop it.

Signed-off-by: Alexey Artamonov <aleksei.artamonov@aenix.io>

2026-09-08 10:47:48 +03:00

..

cozyrd_test.yaml

fix(postgres): stop an unready ScaledObject from wedging the release

2026-09-08 10:47:48 +03:00