Show most relevant message in TigeraStatus kubectl output - #4651
Conversation
…Issues Wire diagnosePods and summarizeIssues into syncState, replacing the old podsFailing/containerErrorMessage functions. Each workload type now reports not-found as a degraded condition instead of silently continuing. DaemonSets and Deployments pass revision info so diagnosePods can distinguish old-revision pods from current ones.
When an object has the unsupported.operator.tigera.io/ignore annotation, surface a warning through TigeraStatus so users know the operator is not managing the resource. Clear the warning if the annotation is later removed.
…applied When the render package applies probe timing or resource overrides to a workload, set an operator.tigera.io/custom-overrides annotation with a comma-separated list of which override types were applied. This will be used by diagnosePods to correlate pod failures with user overrides.
|
This PR is stale because it has been open for 60 days with no activity. |
|
This PR is stale because it has been open for 60 days with no activity. |
electricjesus
left a comment
electricjesus
left a comment
There was a problem hiding this comment.
looks pretty solid to me! a few comments inline.
Two process bits. It needs a rebase, it's conflicting on master now, and createOrUpdateObject grew an installationSpec arg since you branched. CI has also never run here, only the CLA check, so none of this has a green signal yet.
Also worth saying out loud for anyone else reading: GitHub shows 8 files because #4649 was squash merged, so the merge base predates it. The change here is really the one commit.
An older CRD has no message field, so the read-back cannot tell us what we set. The status manager tracks the last message it wrote instead.
There was a problem hiding this comment.
🟡 Changes recommended
The new optional API field does not follow the repo’s “optional fields are pointers” convention, and the statusMessage() helper currently violates its own locking contract unless refactored as suggested.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
This PR improves the usability of kubectl get tigerastatus by introducing a top-level .status.message field that surfaces the most relevant, actionable message (degraded > progressing > warnings > empty) in the default table output, while keeping degraded details available via a separate wide column for skew compatibility.
Changes:
- Add
.status.messageto the TigeraStatus API/CRD and point the defaultkubectlprintcolumn “Message” at it; rename the old degraded “Message” column to “Error” (wide only). - Compute and persist the new top-level status message in the status manager, collapsing multi-line condition messages to a single line for table output.
- Add unit tests covering message precedence, newline collapsing, and behavior under CRD skew (message pruning).
File summaries
| File | Description |
|---|---|
pkg/imports/crds/operator/operator.tigera.io_tigerastatuses.yaml |
Updates CRD schema/printcolumns to add .status.message and introduce a wide-only “Error” column for degraded condition messages. |
pkg/controller/status/status.go |
Computes and writes Status.Message, adds pruning-skew handling via lastMessage, and collapses multi-line condition messages for kubectl output. |
pkg/controller/status/status_test.go |
Adds tests for .status.message precedence, formatting, and pruning-skew behavior. |
api/v1/tigerastatus_types.go |
Adds the Message field to the Go API type and updates kubebuilder printcolumns accordingly. |
Review details
- Files reviewed: 4/4 changed files
- Comments generated: 3
- Review effort level: Lite
💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| // Set the top-level Message field based on the most actionable condition. | ||
| ts.Status.Message = m.statusMessage(ts.Status.Conditions) | ||
|
|
| // statusMessage returns the most actionable message for the top-level Message field, | ||
| // based on the current conditions. Priority: degraded > progressing > warnings > empty. | ||
| func (m *statusManager) statusMessage(conditions []operator.TigeraStatusCondition) string { | ||
| for _, c := range conditions { | ||
| if c.Type == operator.ComponentDegraded && c.Status == operator.ConditionTrue { | ||
| return singleLine(c.Message) | ||
| } | ||
| } | ||
| for _, c := range conditions { | ||
| if c.Type == operator.ComponentProgressing && c.Status == operator.ConditionTrue { | ||
| return singleLine(c.Message) | ||
| } | ||
| } | ||
| return m.warningMessageLocked() | ||
| } |
| // Message is a human-readable summary of the component's current state: the degraded | ||
| // message if degraded, the progressing message if progressing, then any warnings. | ||
| // Empty when healthy with no warnings. | ||
| // +optional | ||
| Message string `json:"message,omitempty"` |
Adds a top-level message to TigeraStatus and points the
kubectl get tigerastatusMESSAGE column at it instead of the Degraded condition message. Previously the column only showed content when the component was degraded, so warnings and rollout detail needed-o yamlto see.The message picks the most actionable thing available, in order:
The degraded message keeps a column of its own under
-o wide, so it stays available on a version skew in either direction.Example output when a component has a warning but is otherwise healthy:
Example output during rollout: