Re: [OpenDaylight TSC] Request Creation Review for Cardinal - OpenDaylight Monitoring as a Service

Jesse White <jesse@...>


On 04/07/2016 12:17 PM, Colin Dixon wrote:
I wanted to take this opportunity to follow up with the creation review along two threads.

First, I'm not sure if you're aware, but the OpenNMS guys (two of which are cc'ed) have been working on integrating
OpenNMS with OpenDaylight in a variety of ways that are very similar to what was proposed in Cardinal. It might be worth
talking a bit about where there's commonality and seeing if there's room for collaboration.
Thanks for looping us in Colin.

From what I gather the Cardinal project is adding SNMP support to ODL, allowing the ODL controller to be monitored using
existing NMSs. Lacking SNMP support we have opted to integrate using the existing interfaces, notably JMX and RESTconf.

That said, if SNMP support (provided by Cardinal) were available we could also evaluate monitoring the ODL controller(s)
via SNMP, making OpenNMS a consumer of this service.

Aside from monitoring the JVM and the state of the Karaf services, we believe there is also value in generating
autonomous events or traps for application specific faults such as "pushing this flow failed", or "this intent could not
be realized due to the current operational constraints". Is this within the scope of the Cardinal project?

Second, Ed (cc'ed) and I talked about the OpenDaylight deployment model and how requiring an external daemon might
complicate things. In essence, we've found the most successful OpenDaylight projects provide some out-of-the-box
features by just downloading the Karaf distribution, unzipping it and running it. If you also require that people
download and install snmpd and snmptrapd, it decreases the number of people who will download it and try it out.
I thought it may be worth mentioning that snmp4j can also be used to setup an agent and sends traps, allowing this
functionality to be embedded in the JVM instead of relying external services. Perhaps this could be used as the default
implementation instead of registering as a snmpd sub-agent?


Join { to automatically receive all group messages.