unit mistakenly considered ready if HelmRelease is suspended

In a situation where a unit HelmRelease is suspended, the Kustomization health-check that tests its readiness will wrongly conclude that the unit is ready.

This creates risks of inconsistencies, in particular the possibility of breaking the ordering in which we expect to be imposed on upgrades (e.g. wrongly considering the cluster unit up-to-date and upgrading units before the Kubernetes is actually upgraded -- this would happen if the cluster unit is suspended).

Cause

This is due to the fact that kstatus library only uses the status.observedGeneration (which is updated when the HelmRelease controller process spec.suspend: true) but does not use the observedGeneration of the status.conditions (this observedGeneration, in the case of a suspended resources, is kept to the old observedGeneration, and comparing it to metadata.generation allows to conclude that this condition is obsolete, avoiding to mistakenly consider that the resource is ready.

Solution

We should be able to workaround this problem by always including in spec.healthCheckExprs a custom CEL expression that would compare metadata.generation and status.conditions[type=Ready].observedGeneration.

/cc @feleouet