Date
1 - 6 of 6
[OpenDaylight TSC] Request Creation Review for Cardinal - OpenDaylight Monitoring as a Service
|
Colin Dixon
Given that there is a PoC alread, I'm guessing that you will need to have an incoming code intellectual property review (IPR). Phil will help you with that if you send him a zip file or tarball with current code. --ColinOn Mon, Mar 28, 2016 at 11:27 AM, Colin Dixon <colin@...> wrote:
|
|
|
|
Colin Dixon
Also, the sooner you can your M1 status report in, the better. You can find the request here: https://lists.opendaylight.org/pipermail/release/2016-March/006027.html Please send it to the release list and make sure that at least one person is subscribed to the release list. On Thu, Mar 31, 2016 at 1:55 PM, Colin Dixon <colin@...> wrote:
|
|
|
|
Colin Dixon
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.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. That's not to say you couldn't have that be one option. For example, the TSDR project supports HSQLDB out-of-the-box without anything else and can be configured to use Cassandra and/or HBASE as well. Neither of these are in any way a requirement, just suggestions/advice about what people have found works. Cheers, --ColinOn Thu, Mar 31, 2016 at 2:15 PM, Colin Dixon <colin@...> wrote:
|
|
|
|
Jesse White <jesse@...>
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.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? 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? Best, Jesse |
|
|
|
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 =====-----=====-----===== |
|
|
|
Jesse White <jesse@...>
Gaurav;
On 04/11/2016 07:03 AM, Pande Gaurav wrote: Sounds good. We can collaborate on this one if you're interested.//**Gaurav**// However, we will surely look into the above application specific faults and evaluate if the same can beincorporated into our ODL-Boron release plan We use the jsmiparser for compiling MIBs, Enterprise MIBs included. Example usage here: https://github.com/OpenNMS/opennms/blob/develop/features/mib-compiler/src/main/java/org/opennms/features/mibcompiler/services/JsmiMibParser.java Best, Jesse |
|
|