You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
processPolicyNodeStatus() handles the PolicyReady case with a bare s.SuccessfulNodes++ — the ready node names are discarded. We keep names for failed/missing (nodesWithIssues) and transitioning (nodesTransitioning), but not for ready. The UI (Node Enforcements tab) wants to render one row per Ready node, and this can't be derived from the CRD: we have the failed and transitioning names plus a total count, but not the total set, so there's nothing to subtract from to recover the ready set.
We should add nodesReady []string, populated in the PolicyReady branch, mirroring the existing nodesTransitioning machinery.
The catch is scale: nodesWithIssues and nodesTransitioning are capped at 20 (maxNodesWithIssues / maxTransitioningNodes) specifically to bound status size. Ready nodes are the common case and can be in the hundreds, so a naive full []string dump has a real etcd/status-size cost. We need a maxReadyNodes cap with the same truncation-marker convention, and successfulNodes stays the authoritative count.
Notes:
Mirror addTransitioningNode: an addReadyNode(nodeName) with a maxReadyNodes cap and the ... truncation marker; clear it in resetPolicyNodeStatus; sort it in the final ordering block for stable status writes.
successfulNodes remains the source of truth for the count; the list may be truncated, so the UI renders "N ready (showing first M)".
No agent/proto change — the agent already reports per-node PolicyStatus; the controller already knows which nodes are ready, it just drops the names.
api/v1alpha1/workloadpolicy_types.go: add NodesReady []string to WorkloadPolicyStatus.
api/v1alpha1/policy_node_status.go: add maxReadyNodes const and addReadyNode(); call it in the PolicyReady case of processPolicyNodeStatus(); clear in resetPolicyNodeStatus(); include in the final sort.
api/v1alpha1/policy_node_status_test.go: cover population, cap/truncation marker, sorting, and reset.
Regenerate CRD manifests + deepcopy, and docs/crd.adoc / docs/crds.
processPolicyNodeStatus()handles thePolicyReadycase with a bares.SuccessfulNodes++— the ready node names are discarded. We keep names for failed/missing (nodesWithIssues) and transitioning (nodesTransitioning), but not for ready. The UI (Node Enforcements tab) wants to render one row per Ready node, and this can't be derived from the CRD: we have the failed and transitioning names plus a total count, but not the total set, so there's nothing to subtract from to recover the ready set.We should add
nodesReady []string, populated in thePolicyReadybranch, mirroring the existingnodesTransitioningmachinery.The catch is scale:
nodesWithIssuesandnodesTransitioningare capped at 20 (maxNodesWithIssues/maxTransitioningNodes) specifically to bound status size. Ready nodes are the common case and can be in the hundreds, so a naive full[]stringdump has a real etcd/status-size cost. We need amaxReadyNodescap with the same truncation-marker convention, andsuccessfulNodesstays the authoritative count.Notes:
addTransitioningNode: anaddReadyNode(nodeName)with amaxReadyNodescap and the...truncation marker; clear it inresetPolicyNodeStatus; sort it in the final ordering block for stable status writes.successfulNodesremains the source of truth for the count; the list may be truncated, so the UI renders "N ready (showing first M)".PolicyStatus; the controller already knows which nodes are ready, it just drops the names.Touchpoints:
api/v1alpha1/workloadpolicy_types.go: addNodesReady []stringtoWorkloadPolicyStatus.api/v1alpha1/policy_node_status.go: addmaxReadyNodesconst andaddReadyNode(); call it in thePolicyReadycase ofprocessPolicyNodeStatus(); clear inresetPolicyNodeStatus(); include in the final sort.api/v1alpha1/policy_node_status_test.go: cover population, cap/truncation marker, sorting, and reset.docs/crd.adoc/docs/crds.