Conversation
dosubot
bot
added
the
size:M
cnpg-bot
added
backport-requested ◀️
Contributor
|
❗ By default, the pull request is configured to backport to all release branches.
|
Member
Author
|
/test |
Contributor
|
@armru, here's the link to the E2E on CNPG workflow run: https://github.com/cloudnative-pg/cloudnative-pg/actions/runs/22761653231 |
leonardoce
approved these changes
Mar 10, 2026
…clusters (#10024) When the hibernation annotation is set on a non-healthy cluster (e.g. CrashLoopBackOff), the operator correctly defers hibernation until the cluster recovers. However, this decision was previously silent — no condition was set, leaving `cnpg status` unable to report why hibernation had not started. This is a purely additive fix. No pre-existing behavior is altered: - Healthy clusters requesting hibernation still proceed immediately - Already-ongoing hibernation (DeletingPods, WaitingPodsDeletion, Hibernated) still bypasses the healthy-phase guard - Clusters without the annotation remain unaffected The only new behavior is that non-healthy clusters with the hibernation annotation now receive a WaitingForHealthy condition (Status=False), providing clear feedback through `cnpg status` where previously there was none. Closes #10024 Signed-off-by: Armando Ruocco <[email protected]>
Signed-off-by: Marco Nenciarini <[email protected]>
mnencia
approved these changes
Mar 11, 2026
cnpg-bot
pushed a commit
that referenced
this pull request
Mar 11, 2026
…clusters (#10193) When the hibernation annotation is set on a non-healthy cluster (e.g. CrashLoopBackOff), the operator correctly defers hibernation until the cluster recovers. However, this decision was previously silent — no condition was set, leaving `cnpg status` unable to report why hibernation had not started. This PR addresses the missing reporting aspect of the issue. Non-healthy clusters with the hibernation annotation now receive a `WaitingForHealthy` condition (`Status=False`), providing clear feedback through `cnpg status` where previously there was none. The underlying behavior — deferring hibernation until the cluster is healthy — remains unchanged. No pre-existing behavior is altered: - Healthy clusters requesting hibernation still proceed immediately - Already-ongoing hibernation (DeletingPods, WaitingPodsDeletion, Hibernated) still bypasses the healthy-phase guard - Clusters without the annotation remain unaffected Note: this does not solve the broader problem of hibernating a cluster that will never become healthy on its own (e.g. persistent CrashLoopBackOff). That would require a separate discussion about allowing forced hibernation when PVCs are already fully provisioned. Ref #10024 Signed-off-by: Armando Ruocco <[email protected]> Signed-off-by: Marco Nenciarini <[email protected]> Co-authored-by: Marco Nenciarini <[email protected]> (cherry picked from commit ff48dfa)
cnpg-bot
pushed a commit
that referenced
this pull request
Mar 11, 2026
…clusters (#10193) When the hibernation annotation is set on a non-healthy cluster (e.g. CrashLoopBackOff), the operator correctly defers hibernation until the cluster recovers. However, this decision was previously silent — no condition was set, leaving `cnpg status` unable to report why hibernation had not started. This PR addresses the missing reporting aspect of the issue. Non-healthy clusters with the hibernation annotation now receive a `WaitingForHealthy` condition (`Status=False`), providing clear feedback through `cnpg status` where previously there was none. The underlying behavior — deferring hibernation until the cluster is healthy — remains unchanged. No pre-existing behavior is altered: - Healthy clusters requesting hibernation still proceed immediately - Already-ongoing hibernation (DeletingPods, WaitingPodsDeletion, Hibernated) still bypasses the healthy-phase guard - Clusters without the annotation remain unaffected Note: this does not solve the broader problem of hibernating a cluster that will never become healthy on its own (e.g. persistent CrashLoopBackOff). That would require a separate discussion about allowing forced hibernation when PVCs are already fully provisioned. Ref #10024 Signed-off-by: Armando Ruocco <[email protected]> Signed-off-by: Marco Nenciarini <[email protected]> Co-authored-by: Marco Nenciarini <[email protected]> (cherry picked from commit ff48dfa)
cnpg-bot
pushed a commit
that referenced
this pull request
Mar 11, 2026
…clusters (#10193) When the hibernation annotation is set on a non-healthy cluster (e.g. CrashLoopBackOff), the operator correctly defers hibernation until the cluster recovers. However, this decision was previously silent — no condition was set, leaving `cnpg status` unable to report why hibernation had not started. This PR addresses the missing reporting aspect of the issue. Non-healthy clusters with the hibernation annotation now receive a `WaitingForHealthy` condition (`Status=False`), providing clear feedback through `cnpg status` where previously there was none. The underlying behavior — deferring hibernation until the cluster is healthy — remains unchanged. No pre-existing behavior is altered: - Healthy clusters requesting hibernation still proceed immediately - Already-ongoing hibernation (DeletingPods, WaitingPodsDeletion, Hibernated) still bypasses the healthy-phase guard - Clusters without the annotation remain unaffected Note: this does not solve the broader problem of hibernating a cluster that will never become healthy on its own (e.g. persistent CrashLoopBackOff). That would require a separate discussion about allowing forced hibernation when PVCs are already fully provisioned. Ref #10024 Signed-off-by: Armando Ruocco <[email protected]> Signed-off-by: Marco Nenciarini <[email protected]> Co-authored-by: Marco Nenciarini <[email protected]> (cherry picked from commit ff48dfa)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When the hibernation annotation is set on a non-healthy cluster (e.g. CrashLoopBackOff), the operator correctly defers hibernation until the cluster recovers. However, this decision was previously silent — no condition was set, leaving
cnpg statusunable to report why hibernation had not started.This PR addresses the missing reporting aspect of the issue. Non-healthy clusters with the hibernation annotation now receive a
WaitingForHealthycondition (Status=False), providing clear feedback throughcnpg statuswhere previously there was none. The underlying behavior — deferring hibernation until the cluster is healthy — remains unchanged.No pre-existing behavior is altered:
Note: this does not solve the broader problem of hibernating a cluster that will never become healthy on its own (e.g. persistent CrashLoopBackOff). That would require a separate discussion about allowing forced hibernation when PVCs are already fully provisioned.
Ref #10024