The annotation comment repeated the PR description and the test header;
two lines on why are enough. The hang comes from the kstatus generation
check in cli-utils, not the CEL status evaluator, since vm-instance sets
no healthCheckExprs. The config-hash rollout runs in cozystack-controller,
not cozystack-operator.
Assisted-by: LLM
Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>
The generated HelmRelease is health-assessed by helm-controller's kstatus
poller, which returns InProgress for any object whose
status.observedGeneration trails metadata.generation: a built-in pre-check
in fluxcd/pkg/runtime/cel that runs before, and cannot be overridden by,
healthCheckExprs. KubeVirt legitimately keeps a VirtualMachine's
observedGeneration behind its generation while a template change is pending
a restart, the VM is stopped, or a live-updatable change never converges
(kubevirt/kubevirt#18700), so a healthy Running VM is read as permanently
InProgress and the release never reaches Ready. Releases still carrying the
pre-1.5.0 remediation.retries:-1 + rollback spec then revert the previous
manifest, dropping just-applied changes such as opened ports.
Disable the readiness wait so the release settles once the VirtualMachine is
applied; VM health is observed on the VirtualMachine itself. This restores
the pre-1.5.0 behaviour under which the VM was never a helm readiness gate.
A helm-unittest suite guards that the annotation stays in place.
Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>
IvanHunters