[OpenNMS/opennms] b37a4e: NMS-20254: Carry a discovered link's interfaces on...

  Branch: refs/heads/mm/NMS-20254-smoke
  Home:   https://github.com/OpenNMS/opennms
  Commit: b37a4e768cc1e66bc46678ce3af75c19a415dc3b
      https://github.com/OpenNMS/opennms/commit/b37a4e768cc1e66bc46678ce3af75c19a415dc3b
  Author: Marshall Massengill <[email protected]>
  Date:   2026-08-24 (Mon, 24 Aug 2026)

  Changed paths:
    M features/graph/provider/legacy/pom.xml
    M features/graph/provider/legacy/src/main/java/org/opennms/netmgt/graph/provider/legacy/LegacyEdge.java
    A features/graph/provider/legacy/src/test/java/org/opennms/netmgt/graph/provider/legacy/LegacyEdgeTest.java
    A features/topology-map/org.opennms.features.topology.api/src/main/java/org/opennms/features/topology/api/topo/LinkDetailsAware.java
    M features/topology-map/plugins/org.opennms.features.topology.plugins.topo.linkd/src/main/java/org/opennms/features/topology/plugins/topo/linkd/internal/LinkdEdge.java
    M features/topology-map/plugins/org.opennms.features.topology.plugins.topo.linkd/src/test/java/org/opennms/features/topology/plugins/topo/linkd/internal/EnhancedLinkdTopologyProviderTest.java

  Log Message:
  -----------
  NMS-20254: Carry a discovered link's interfaces onto its graph edge

Enlinkd knows which two interfaces a link runs between. Each link row is
one-sided, holding the local ifIndex and only a label for the far end, but the
service layer pairs the two rows: LldpTopologyService.match() and its siblings
return both sides, each with its own nodeId and ifIndex. The topology updaters
turn that into an OnmsTopologyEdge whose two OnmsTopologyPorts carry ifindex,
ifname, addr and speed, resolved against the SNMP interface table. The Vaadin
plugin keeps it, on LinkdEdge's source and target ports.

It ends there. Converting a legacy edge to a graph-API edge kept the id, label,
namespace and two endpoint node references, so everything reading /api/v2/graphs
sees a link with no way back to the interfaces it runs between. Nothing was
missing from the data; it was computed and dropped in one constructor.

An edge that knows its link now says so through LinkDetailsAware, and the
conversion copies the two ifIndexes and the discovery protocol into the edge's
properties. The graph REST layer serializes the whole property bag already, so
they reach clients without a change there.

The keys are declared on LegacyEdge rather than in GenericProperties, whose own
javadoc offers it for any element: an ifIndex means nothing on a business-service
or application edge. BusinessServiceEdge nests its keys the same way.

The values are written as strings. Every property in that bag reaches clients as
one, because the graph REST converters have no case for a boxed Integer and fall
through to toString(), so storing an Integer would serialize identically while
claiming to be a number. Existing keys already do this, PathOutageGraphProvider
writing nodeID with String.valueOf.

The protocol goes across because a combined view holds several protocols in one
namespace, where an edge's own protocol is otherwise unrecoverable. All three are
optional: a link discovered from one side resolves one end, the same providers
also serve synthetic topologies whose ends have no interface at all, and the
builder drops nulls, so an unresolved end is absent rather than present and
empty.

The interface, rather than an instanceof on the plugin's own edge class, keeps
the generic graph module from depending on a Vaadin plugin. It lives in the
topology API the legacy provider already imports.

Covered over the path production uses, which is clones: every getEdges() returns
edge.clone(), so the assertions run against real provider-built edges resolved
from the SNMP interface table and then cloned. The conversion's own test needs
Vaadin only because the legacy Edge interface returns a Vaadin Item.

This unblocks the weathermap link-metrics work, which needs (node, ifIndex) per
direction to address interface counters. Note it does not by itself retire the
UI's parseIfIndex regex: that reads the /api/v2/enlinkd/{nodeId} neighbour DTOs,
whereas these properties land on /api/v2/graphs, so retiring it means moving the
UI's interface lookup to a different endpoint.



To unsubscribe from these emails, change your notification settings at https://github.com/OpenNMS/opennms/settings/notifications


_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/wiki/index.php?page=MailingListFaq
opennms-cvs mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-cvs