Repository navigation
bug(tests): the postgres backup example's HelmRelease waits are on the same kstatus path with nothing checking the budget #3748
Description
examples/backups/postgres/run-all.sh:122 and :166 allow the source and target HelmReleases 360 seconds to become Ready. Whether that is enough is unknown, and nothing in the tree would notice if it stopped being enough.
The mechanism is the one established for mariadb in #3744. helm-controller leaves spec.waitStrategy unset for these releases and defaults it to poller, so the install action waits through kstatus. kstatus has no type-specific rules for postgresql.cnpg.io/Cluster, so it falls through to its Ready-condition fallback, which maps Ready=False onto InProgress. A CNPG Cluster does carry a Ready condition, so HelmRelease readiness there spans the cluster coming up, exactly as it does for the operator's MariaDB kind.
What I am not claiming
I am not saying 360 seconds is short. CNPG's first-boot cost is not the mariadb chart's, and I did not measure it. The mariadb number came from a chart that documents its own 310-second startup-probe budget in the template, and postgres has no equivalent figure I could read off. Anyone picking this up should measure before touching the number; changing it on the strength of the mariadb analogy would be substituting one unverified value for another.
What is missing
hack/mariadb-backup-example-waits.bats derives the mariadb budget from the chart's failureThreshold and refuses any wait that does not beat it, in both the example script and the Chainsaw suite. There is no equivalent for postgres, so the same class of defect, a wait quietly sitting below what a healthy first boot needs, would surface as a red suite with no explanation rather than as a failing contract.
Two things have to happen in order, and the second is the reason to file this rather than open a patch: establish what a legal CNPG first boot costs on this platform, from something a test can read rather than from a run that happened to be fast, and only then decide whether 360 clears it and pin the relation.
Activity
lexfrei commentedon Aug 11, 2026
Concrete addresses for this, including two that are easy to miss.
examples/backups/postgres/run-all.sh:122and:166give the postgres HelmRelease 360s each. Neither thepostgresApplicationDefinition norpostgres-rdoverrideshelm-install-timeoutor disables the wait, so the release carries the 600s default: the wait expires four minutes before the install can record why it failed, and the harness reports a bare timeout instead of the reason.The bucket waits have the same problem and sit in a different part of the script, which is why they get missed:
examples/backups/postgres/run-all.sh:41andexamples/backups/mariadb/run-all.sh:52, bothwait_hr_ready "bucket-${BUCKET_NAME}" 300.bucket-rdcarries no override either. Worth taking in the same pass, because raising only the postgres pair leaves two waits under the same floor, one of them in the mariadb example.lexfrei commentedon Aug 12, 2026
Concrete addresses for this, including two that are easy to miss.
examples/backups/postgres/run-all.sh:122and:166give the postgres HelmRelease 360s each. Neither thepostgresApplicationDefinition norpostgres-rdoverrideshelm-install-timeoutor disables the wait, so the release carries the 600s default: the wait expires four minutes before the install can record why it failed, and the harness reports a bare timeout instead of the reason.The bucket waits have the same problem and sit in a different part of the script, which is why they get missed:
examples/backups/postgres/run-all.sh:41andexamples/backups/mariadb/run-all.sh:52, bothwait_hr_ready "bucket-${BUCKET_NAME}" 300.bucket-rdcarries no override either. Worth taking in the same pass, because raising only the postgres pair leaves two waits under the same floor, one of them in the mariadb example.test(e2e): let HR-Ready waits outlast the install timeout of the rele…