StarGate collapses repeated OpenShift lab failures into fleet-level issues

StarGate, the continuous-operations field build used around Red Hat Demo Platform lab environments, has added a fleet-level known-issues layer intended to turn repeated OpenShift lab failures into a smaller operator queue. The change follows a project audit that found duplicated investigations were consuming more attention than genuinely new failure patterns.

From namespace alerts to shared causes

The project’s November 7 commit says 55% of 34 investigations run during its November 6 production audit duplicated work on the same namespace and failure class. It also says roughly 70% of that day’s failure volume traced back to about four root causes: a chart defect, an unstable router and two StarGate rubric defects.

The previous model could present those repetitions as separate diagnoses because persistent failures emitted fresh evaluation events after short deduplication windows. StarGate now checks for a completed, actionable investigation for the same lab and failure class during a configurable 24-hour window. When it finds one, it attaches a debounced recurrence to the earlier investigation instead of opening another. The project records the recurrence count, last-seen time and a recurrence log.

That is the operational shift: the system keeps evidence that a failure happened again, while asking an operator to work the established diagnosis rather than re-read another copy of it.

Three buckets shape the response

A five-minute background process groups completed investigations that share a root cause into three buckets. platform_self covers StarGate’s own evaluator or rubric defects; platform covers infrastructure-side problems; and lab_family covers shared chart or configuration artifacts across related labs. Each persisted known issue includes a signature, affected namespace and investigation counts, first- and last-seen times, a representative investigation, root-cause and remediation excerpts, and artifact references.

Operators can read the rollup through a dashboard endpoint or the get_known_issues MCP tool. The project’s example is deliberately concrete: “ten investigations, one chart bug” should appear as one issue. This can change triage order because a cross-cluster platform defect can be separated from one lab family’s shared deployment artifact, while StarGate’s own false-positive-producing rubric is called out as a platform-self problem.

The evidence model still matters

The rollup inherits StarGate’s broader causal-chain model: symptom, evidence, diagnosis, adjudication, action, remediation and verification, with missing links reported rather than silently filled. Only completed investigations feed the known-issues detector, and the new 24-hour suppression applies to actionable diagnoses. The project explicitly leaves transient diagnoses eligible for reinvestigation.

Those constraints matter because recurrence is not proof that two failures have the same cause. The grouping code relies on normalized failure classes, root-cause text, cluster context and artifact references produced by earlier investigations. A weak or incorrect diagnosis can therefore become a convincing-looking fleet issue. StarGate’s design reduces that risk by retaining the representative investigation and evidence references, but operators still have to review the causal chain.

The known-issues loop is also read-and-upsert only: it has no execution authority. Remediation remains behind StarGate’s separate approval, risk, rate-limit and execution-mode gates. The commit reports that 16 seeded investigations reproduced the three issues found in the audit and that 2,239 tests passed, while noting pre-existing cluster-access test failures. GitHub’s commit page showed failing status checks when this desk reviewed it, so the production claims remain project-reported rather than independently verified.

For platform teams running shared OpenShift workshops, the useful idea is not automatic closure. It is a queue that preserves recurrence evidence while making the unit of work the suspected fleet cause—not every namespace that expresses it.