PR : https://github.com/OpenNMS/opennms/pull/3113

I have a few concerns with the current implementation:

• There's too much logic & work being done in the "parser"

• The OpenConfig code is responsible for more than just the protocol work (i.e. watching services, scheduling, etc...)

• Meta-data is used to drive the configuration as opposed to just enrich it

I've attached a document with some background and propose a different approach that handles these concerns.

Proof-of-concept code is available here: https://github.com/OpenNMS/opennms/tree/jw/openconfig

Connectors are defined here: https://github.com/OpenNMS/opennms/blob/fc608a77196f65524b49b832652dc0e3ef5b55e9/features/telemetry/api/src/main/java/org/opennms/netmgt/telemetry/api/receiver/Connector.java#L44

The life-cycle of the connectors are managed here:

https://github.com/OpenNMS/opennms/blob/fc608a77196f65524b49b832652dc0e3ef5b55e9/features/telemetry/daemon/src/main/java/org/opennms/netmgt/telemetry/daemon/ConnectorManager.java#L125

The FilterService abstracts service filtering, filter evaluation & event handling:

https://github.com/OpenNMS/opennms/blob/fc608a77196f65524b49b832652dc0e3ef5b55e9/opennms-dao-api/src/main/java/org/opennms/netmgt/dao/api/FilterService.java#L77

(implementation needs to be fleshed out)

PR: https://github.com/OpenNMS/opennms/pull/3040

Although this can be envisioned as part of Telmetryd daemon since this involves a client that does bi-directional RPC this may not really fit into listener.

As a first step develop client and then see if we can fit this as part of Telemetryd.