mirror of
https://github.com/cozystack/cozystack.git
synced 2026-11-09 14:02:56 +09:00
Aleksei Sviridkin
3d317c5f67
## What this PR does Tenants usually read Applications but not the HelmReleases behind them, and the Application status only carried the `Ready` and `Released` conditions. A client could see that a release was failing, but not how many times it had failed or whether helm-controller had stopped retrying it. This PR copies the `Stalled` condition onto the Application and adds three optional status fields taken from the HelmRelease: `installFailures`, `upgradeFailures` and `lastAttemptedReleaseAction`. All of them are additive and `omitempty`, so existing clients are unaffected. What the new fields do and do not tell a client: - With the `RetryOnFailure` policy the platform generates today, a failed release is retried rather than stalled, so the counters are the signal. That does not hold for every state: a release missing from Helm storage while an install failure count is retained still stalls (the case in #3554), a release on a remediation policy stalls once its retries run out, and terminal errors such as an invalid CEL expression or denied access stall too. - `Stalled` is copied only when it was observed for the HelmRelease's current generation. The Application carries no generation, so after a spec update a client would otherwise read the previous spec's failure as terminal for the new values; until helm-controller reconciles the new spec, the Application shows no `Stalled`. - The counters only count attempts that recorded a Helm release. A failure before Helm records one, such as a chart that fails to render (for example a `fail` guard rejecting the values), shows only as `Ready=False` and leaves them at zero; a failure to apply the rendered resources is counted. - helm-controller resets the counters when the desired state changes (generation, chart version, values), and on success only under `RetryOnFailure`, so a `Ready` release can still carry non-zero counters. The field descriptions say so. `TenantModule` is left unchanged on purpose: it still copies only `Ready` and `Released`. Related: #5109, #4155 Tests cover the copied condition and counters, a `Stalled` left over from an older generation after a spec update, the counters kept on a `Ready` release, and that `Reconciling` is still not copied. The OpenAPI schema and apply configurations are regenerated, and every per-kind status schema picks up the new fields. ### Screenshots Not a UI change. ### Downstream repositories - [x] No downstream repository is affected by this change - [ ] [cozystack/website](https://github.com/cozystack/website) - follow-up: - [ ] [cozystack/terraform-provider-cozystack](https://github.com/cozystack/terraform-provider-cozystack) - follow-up: - [ ] [cozystack/ansible-cozystack](https://github.com/cozystack/ansible-cozystack) - follow-up: - [ ] [cozystack/ccp](https://github.com/cozystack/ccp) - follow-up: - [ ] [cozystack/talm](https://github.com/cozystack/talm) - follow-up: - [ ] [cozystack/cozyhr](https://github.com/cozystack/cozyhr) - follow-up: - [ ] [cozystack/cozy-proxy](https://github.com/cozystack/cozy-proxy) - follow-up: - [ ] [cozystack/cozystack-telemetry-server](https://github.com/cozystack/cozystack-telemetry-server) - follow-up: - [ ] [cozystack/external-apps-example](https://github.com/cozystack/external-apps-example) - follow-up: - [ ] [cozystack/examples](https://github.com/cozystack/examples) - follow-up: - [ ] [cozystack/community](https://github.com/cozystack/community) - follow-up: The Terraform provider reads only the `Ready` condition by type, so the extra condition and fields do not change its behaviour. The website only shows an example Application output, not a description of the status contract. ### Release note ```release-note feat(api): Applications now expose the HelmRelease `Stalled` condition and the `installFailures`, `upgradeFailures` and `lastAttemptedReleaseAction` status fields, so tenants without access to HelmReleases can see how a release is failing. Tools that compute health with kstatus, such as Flux Kustomizations waiting on Applications, now report an Application whose release has stalled as failed. ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> <!-- coderabbit-ai-generated:v1 --> ## Summary by CodeRabbit * **New Features** * Application status now displays install and upgrade failure counts, along with the most recently attempted release action. Failure counts reflect attempts recorded as releases and reset when the desired state changes. * Current stalled release conditions are now reflected in application status, helping clarify when a release is blocked. * Failure details remain available when a release is ready, while reconciling conditions are not shown. <!-- end of auto-generated comment: release notes by coderabbit.ai -->