From e9c797fc1e834f87bccea053353be22519927a8b Mon Sep 17 00:00:00 2001 From: Hongkai Liu Date: Fri, 1 May 2026 11:45:21 -0400 Subject: [PATCH] Clarify cluster operator Progressing condition It clarifies that a new node from cluster scaleup or rebooting during cluster upgrade does not trigger COs to go Progressing. DaemonSet is an example and commonly seen in CI. It could be any Kubernetes resource that manages pods. I hope that this helps reduce the confusion from CO owners [1]. Todo: Sync the change to counterpart in o/enhancement [2] if it is accepted. [1]. https://redhat.atlassian.net/browse/OCPBUGS-62629?focusedCommentId=16850780 [2]. https://github.com/openshift/enhancements/blob/master/dev-guide/cluster-version-operator/dev/clusteroperator.md#conditions --- config/v1/types_cluster_operator.go | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/config/v1/types_cluster_operator.go b/config/v1/types_cluster_operator.go index 83230403893..e934e835505 100644 --- a/config/v1/types_cluster_operator.go +++ b/config/v1/types_cluster_operator.go @@ -160,8 +160,9 @@ const ( // is actively rolling out new code, propagating config changes (e.g, a version change), or otherwise // moving from one steady state to another. Operators should not report // Progressing when they are reconciling (without action) a previously known - // state. Operators should not report Progressing only because DaemonSets owned by them - // are adjusting to a new node from cluster scaleup or a node rebooting from cluster upgrade. + // state. Operators should not report Progressing only because resources owned by them, + // such as DaemonSets and Deployments, are adjusting to a new node from cluster scaleup + // or a node rebooting from cluster upgrade. // If the observed cluster state has changed and the component is // reacting to it (updated proxy configuration for instance), Progressing should become true // since it is moving from one steady state to another.