NMS-19644: Expose SnmpInterfaceDao and ResourceDao in GraphML infopanel context

[dino2gnt]

Expose an SnmpInterfaceDao and a ResourceDao in the graphml infopanel context. This allows the user to enumerate SnmpInterfaces, for example to locate a specific interface using properties from the graphml topo, or leverage the ResourceDao to quickly build a resourceId to pass to the measurements helper, or dynamically determine if a specific resource or attribute exists.

I think this will be helpful, and I'd rather have it and not need it than need it and not have it.

External References

• Jira (Issue Tracker): https://opennms.atlassian.net/browse/NMS-19644

[dino2gnt]

ResourceDao taking a OnmsNode is super inconvenient :/

[dino2gnt]

Accidentally polluted this with a cherry-pick from develop that is required to build RPMs in my environment, which I have now reverted.

[garcia-sr]

LGTM! Very awesome.

[synqotik]

LGTM

[cgorantla]

@dino2gnt Check if we can avoid adding nodeDao and snmpInterfaceDao here.

Also better to add objects instead of Daos for this context.

[cgorantla]

Looks like we already have node object in context from which we can derive snmp interfaces.

[dino2gnt]

The node is only populated if the graphml topology defines a nodeID property, or foreignID and foreignSource on the vertex. In the particular case I'm working with, most of the topology is describing edges (i.e. links between vertexes), not actual vertexes, so there are properties defined that describe both ends of the link with the expectation that clicking on the link will show metrics from both the "local" and "remote" side of the "edge". That's a long way of saying node is never populated in this use case and even if it were, it would only get us half the data the customer wants.

The problem I'm ultimately trying to solve is that I have, in the context of the edge, a foreignsource (known), and a "local" and "remote" foreignid (in the topo) I can leverage fetch the node, and either full or partial "local" and "remote" device interface names from the topo from which to derive a resourceid I can then use to fetch metrics for these layer 1 interfaces. There is also an snmp interface for the layer 3 network interface that has the actual traffic octets metrics. I'm trying to get sufficient tools in the jinjava infopanel context that I can dynamically determine the involved measurements resourceid and metric attributes for the layer 1 interfaces, and the layer 3 interface, without resorting to string mangling and concatenation (because it feels wrong).

I think putting prefetched object instead of the Dao would require knowing beforehand what I need to fetch, and I don't - which is my core problem.

[cgorantla]

exposing these daos will lead to template injection issues. There is no easy way to restrict this to read only from jinjava.

Other way is to write a wrapper and expose read only method and what's needed.

[dino2gnt]

the ResourceDao is okay, though, yeah?

[cgorantla]

the ResourceDao is okay, though, yeah?

even that has ResourceDao.deleteResourceById().
Even for something like drools rules, we only allow specific methods through AlarmService.

I think writing wrapper might be the best way to do this. I can help you here.

Looks like there are some issues.