mirror of
https://github.com/cozystack/cozystack.git
synced 2026-10-29 16:17:20 +09:00
Myasnikov Daniil
b5525f5b94
Update rebuilds the HelmRelease from the Application and writes it back
whole, and the Application carries no suspension, so every edit made
through the API resumed a release that an operator or a controller had
suspended.
The CNPG restore driver depends on that suspension. It suspends the
target release, patches the Postgres app through this API, purges the
Cluster, and resumes only once the purge is done, so the chart's next
render lands bootstrap.recovery on an empty namespace. Resumed by the
patch instead, helm-controller upgrades straight away: the chart can
render the recovery Cluster while the purge is still running, the
driver then deletes it as the Cluster being replaced, and nothing
renders it again because the values have not changed since. The
RestoreJob sits in Running until its deadline.
On main this has been masked by timing rather than prevented. The same
write also dropped the Flux finalizer, so helm-controller's first pass
after it only put the finalizer back and requeued, which held the
upgrade back by at least its 750ms minimum retry delay. A branch that
keeps the finalizer removes that delay, and the backup round-trip
failed on both of its runs there.
The suspension is re-read on a conflict retry as well, since the write
that caused the conflict may be the suspend itself.
The conflicts were in the comments of REST.Update, where this branch
already carries the metadata carry-over of the HelmRelease. The two
Spec.Suspend assignments merged unchanged and the comments read as
they do on main.
Assisted-by: LLM
(cherry picked from commit 5df219b37a)
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>