Skip to content

Commit c7264a5

Browse files
committed
fix(monitoring): correct stale 'render-rejected when empty' comments
The healthCheckExprs comment (and the mirroring test comment) still claimed tracingStorages is render-rejected when empty and that the 'Ready with no trace store' hole cannot be reached — but the off-by-default change in this PR removed that guard and made empty the default. Rewrite both to state the actual behaviour: empty is the default (tracing off), so the exprs are usually inert (Flux evaluates them only against CRs present in the inventory), and a Ready release with no trace store is intentional and harmless because nothing produces spans until the collector ships — no fail-on-empty guard, and none needed yet. Signed-off-by: Alexey Artamonov <[email protected]>
1 parent aa72bb1 commit c7264a5

2 files changed

Lines changed: 10 additions & 4 deletions

File tree

‎packages/extra/monitoring/templates/helmrelease.yaml‎

Lines changed: 7 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -51,8 +51,13 @@ spec:
5151
#
5252
# The traces backend (VTCluster / VTSingle) uses the same operator and the
5353
# same status.updateStatus contract as VLCluster, so it is gated identically.
54-
# tracingStorages is likewise render-rejected when empty (templates/vtraces/
55-
# vtraces.yaml), so the "Ready with no trace store" hole cannot be reached.
54+
# Unlike logs, tracingStorages is EMPTY by default (tracing off), so usually
55+
# no VTCluster/VTSingle renders and these exprs are inert — Flux evaluates
56+
# them only against CRs present in the release inventory. That "Ready with no
57+
# trace store" state is intentional and harmless: nothing produces spans until
58+
# the trace collector ships, so no data is dropped (there is no fail-on-empty
59+
# guard on tracingStorages, and none is needed yet — contrast the logs #3181
60+
# guard, which fires because fluent-bit ships logs unconditionally).
5661
healthCheckExprs:
5762
- apiVersion: operator.victoriametrics.com/v1
5863
kind: VLCluster

‎packages/extra/monitoring/tests/helmrelease_test.yaml‎

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -44,8 +44,9 @@ tests:
4444
value: "has(status.updateStatus) && status.updateStatus != 'operational' && status.updateStatus != 'expanding'"
4545

4646
# The traces backend (VTCluster/VTSingle from tracingStorages) is gated the
47-
# same way and by the same operator status contract, closing the same
48-
# "Ready with no store" hole (#3181) for traces. Pin both entries so a
47+
# same way and by the same operator status contract. tracingStorages is empty
48+
# by default, so these exprs are usually inert (no CR to match); when a backend
49+
# is configured they gate readiness on it. Pin both entries so a
4950
# dropped/reordered block or a typo'd CEL expression fails a test rather than
5051
# silently regressing the gate.
5152
- it: gates readiness on the VTCluster status.updateStatus

0 commit comments

Comments
 (0)