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>
Closes IvanHunters' MAJOR on cozyrds/postgres.yaml:12 (coverage half). Dropping the
release.cozystack.io/helm-server-side-apply annotation left the whole suite green: the
Go builder test pins the plumbing that consumes it but nothing pinned the annotation at
the point it is set, so the single load-bearing invariant of the feature — client-side
apply, without which server-side apply reverts KEDA's live /scale on every reconcile —
was unguarded. Add a helm-unittest that renders the ApplicationDefinition and asserts the
annotation, plus a test target so hack/helm-unit-tests.sh runs it; removing the annotation
now goes red.
Signed-off-by: Alexey Artamonov <aleksei.artamonov@aenix.io>
Alexey Artamonov