Skip to content

Commit f994ba4

Browse files
scooby87scooby87
committed
test(opensearch): correct the rolling-restart log order in the roll-gate comment
The podLogs catch comment described the reconciler's log order backwards. It presented CheckClusterStatusForRestart as the "last gate" whose silent hold is detected by the absence of "Starting rolling restart of the StatefulSet". Both halves are wrong. Against opensearch-k8s-operator v2.8.0, that log line prints at rollingRestart.go:155 -- after the early gates (Initialized :123, ready-replica :94, updated/ready-pods :150-154) and before the health gate CheckClusterStatusForRestart at :177 -- so its absence flags an EARLIER gate holding silently, not the health gate. The health gate is not silent and not last: it logs "Couldn't proceed with rolling restart ... because <reason>" at :182 on each 10s requeue (for the mount-plan incident, "waiting for health to be green", os_data_service.go:180), and PreparePodForDelete at :195 follows it. That "Couldn't proceed ... because" line is the real diagnostic for a health hold, which the adjacent tail-size comment already relies on ("one health log per ~10s"); the old framing contradicted it. Rewrite the comment to name the line, keep pointing to the function rather than a position, and preserve the health-vs-reachability wording. Comment-only; the asserts are byte-unchanged. Refs #4259 Signed-off-by: Alexey Artamonov <[email protected]>
1 parent 04fb916 commit f994ba4

1 file changed

Lines changed: 15 additions & 8 deletions

File tree

‎hack/e2e-chainsaw/opensearch/chainsaw-test.yaml‎

Lines changed: 15 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -63,14 +63,21 @@ spec:
6363
- podLogs:
6464
selector: opster.io/opensearch-cluster=opensearch-test
6565
tail: 100
66-
# The restart is the operator's rolling-restart reconciler's to start, and its
67-
# last gate holds until CheckClusterStatusForRestart reports cluster health
68-
# green (or yellow under its .opensearch-observability exception) — a client
69-
# that cannot reach the cluster errors out of that gate, it does not hold it.
70-
# Only that gate logs, so a run whose log lacks "Starting rolling restart of
71-
# the StatefulSet" had an earlier gate in the reconciler hold it silently. The
72-
# verdict is in the operator, not the cluster pods above, and it runs in its
73-
# own namespace.
66+
# The restart is the operator's rolling-restart reconciler's to start. It logs
67+
# "Starting rolling restart of the StatefulSet" once the early gates pass —
68+
# cluster Initialized, every replica ready, an update actually pending — and
69+
# only then reaches the health gate, CheckClusterStatusForRestart, which holds
70+
# the roll until cluster health is green (or yellow under its
71+
# .opensearch-observability exception). A client that cannot reach the cluster
72+
# errors out of that gate, it does not hold it. So a log missing "Starting
73+
# rolling restart" means an earlier gate held silently; the line present and
74+
# followed by "Couldn't proceed with rolling restart ... because <reason>"
75+
# means the roll reached the health/pod-delete stage and that reason names what
76+
# held — "waiting for health to be green" for the mount-plan incident. That
77+
# "Couldn't proceed ... because" line is the health hold's signal, one per ~10s
78+
# requeue and what the tail below is sized for, and CheckClusterStatusForRestart
79+
# is not the last gate: PreparePodForDelete follows it. The verdict is in the
80+
# operator, not the cluster pods above, and it runs in its own namespace.
7481
- podLogs:
7582
namespace: cozy-opensearch-operator
7683
selector: control-plane=controller-manager

0 commit comments

Comments
 (0)