Re: [OpenDaylight TSC] Request Creation Review for Cardinal - OpenDaylight Monitoring as a Service
|
Pande Gaurav <pande.gaurav@...>
Hi Jesse, Colin,
toggle quoted message
Show quoted text
Thanks for the inputs. Please find clarifications to the queries marked with tag //**Gaurav**//. Thanks and Regards, Gaurav Pande Tata Consultancy Services -----Jesse White <jesse@...> wrote: ----- To: Colin Dixon <colin@...>, Pande Gaurav <pande.gaurav@...>, "project-proposals@..." <project-proposals@...> From: Jesse White <jesse@...> Date: 04/07/2016 11:45PM Cc: "tsc@..." <tsc@...>, Partha Datta <partha.datta@...>, Srivastava Rajani <srivastava.rajani@...>, Philip Robb <probb@...>, cgallen@..., Ed Warnicke <hagbard@...> Subject: Re: [OpenDaylight TSC] Request Creation Review for Cardinal - OpenDaylight Monitoring as a Service All; 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. //**Gaurav**// That is correct. With Cardinal project (in OpenDaylight Boron) - Open-source / Vendor NMS' will be able to start monitoring OpenDaylight. Yes - the NMS will be 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? //**Gaurav**// Agreed. As part of the Cardinal plan, in ODL-Boron release OpenDaylight System Info, Karaf / MD-SAL parameters pertaining to feature/plugin status/scalability will be provided. In the ODL-Carbon release (as discussing during TSC review) the network parameters will be looked into. //**Gaurav**// However, we will surely look into the above application specific faults and evaluate if the same can be incorporated into our ODL-Boron release plan > > 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? //**Gaurav**// Agreed. Based on the inputs received during TSC review, we were also investigating on usage of a native library (instead of the likes of Net-SNMP) //**Gaurav**// As part of investigation, our view on a OpenDaylight MIB (as part of Cardinal project is as follows): 1) Enterprise MIB:
2) Experimental MIB:
Within OpenNMS, are there any open-source MIB compilers being used ? We looked into "mib2opennms" - but per our understanding is only to extract all the NOTIFICATION-TYPEs in OpenNMS eventconf.xml format. Best, Jesse =====-----=====-----===== |
|
|