kmesh: waypoints/nodeinfo: Add related-resource links to detail pages - #1218
kmesh: waypoints/nodeinfo: Add related-resource links to detail pages#1218itvi-1234 wants to merge 1 commit into
Conversation
Signed-off-by: Sumit Goyal <rjsumit71@gmail.com>
Ralthos
left a comment
There was a problem hiding this comment.
The Pods and Services rows are scoped correctly. Both useList calls pass namespace alongside
the istio.io/gateway-name selector, so they cannot pick up a same-named waypoint's workloads
from somewhere else.
The namespaces row does not have that scoping:
const enrolledNamespaces = (namespaces ?? []).filter(
ns => ns.metadata?.labels?.[USE_WAYPOINT_LABEL] === name
);namespaces is an unfiltered cluster-wide list and the predicate compares the waypoint name
only. A Waypoint is namespaced, so two teams can each have one called waypoint. Open the one in
team-a and the row lists every namespace enrolled with team-b's waypoint as well, presented
as namespaces using this one.
The plugin already draws this distinction elsewhere. In the map source on #1206's neighbour
#1215, the service lookup requires both:
const target = kmeshWaypoints.find(
w => w.metadata.name === waypointName && w.metadata.namespace === svc.metadata.namespace
);Two ways to close it, and the choice depends on something I do not know about your deployment
model.
If enrollment is same-namespace only, add && ns.metadata.name === namespace. The row then
resolves to at most the waypoint's own namespace, which may be thin enough that the row is not
worth showing on its own.
If a namespace is meant to be able to point at a waypoint in another namespace, then the name
alone was never enough to resolve it and istio.io/use-waypoint-namespace is the field that
disambiguates. It does not appear anywhere in this diff.
Either way the current predicate answers a question nobody asked, which is "which namespaces
name a waypoint with this string".
The two tests here pass because the fixtures have one namespace each. A third fixture, with a
second namespace enrolled against a same-named waypoint elsewhere, would fail today and is the
case worth pinning.
There was a problem hiding this comment.
Pull request overview
Adds related Kubernetes resource links to Waypoint and KmeshNodeInfo detail pages.
Changes:
- Links Waypoints to proxy Pods, Services, and enrolled Namespaces.
- Links KmeshNodeInfo resources to Nodes and daemon Pods.
- Adds Waypoint related-resource tests.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
kmesh/src/components/waypoints/Detail.tsx |
Adds Waypoint related resources. |
kmesh/src/components/waypoints/Detail.test.tsx |
Tests related-resource rendering. |
kmesh/src/components/nodeinfo/Detail.tsx |
Adds Node and daemon Pod links. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| ); | ||
| } | ||
|
|
||
| function WaypointRelatedResources({ name, namespace }: { name: string; namespace: string }) { |
| const [daemonPodObject] = K8s.ResourceClasses.Pod.useGet( | ||
| daemonPod?.name ?? '', | ||
| daemonPod?.namespace ?? '' | ||
| ); |
| expect(screen.getByText('my-waypoint-abcde')).toBeTruthy(); | ||
| expect(screen.getByText('team-a')).toBeTruthy(); | ||
| expect(screen.queryByText('team-b')).toBeNull(); |
| const enrolledNamespaces = (namespaces ?? []).filter( | ||
| ns => ns.metadata?.labels?.[USE_WAYPOINT_LABEL] === name | ||
| ); |
Summary
istio.io/gateway-namelabel set by the Gateway API deployer), and any Namespaces enrolled to use that waypoint (viaistio.io/use-waypoint).