Google Summer of Code 2012

From OpenNMS
Jump to navigation Jump to search


What Is OpenNMS

OpenNMS is an enterprise grade network management framework developed under the open source model. It consists of a community supported open-source project sponsored by a commercial services, training and support organization, The OpenNMS Group, Inc.

The goal is for OpenNMS to be a truly distributed, scalable platform supporting all aspects of the FCAPS network management model as well as a framework for implementation of NGOSS components making OpenNMS a platform available to both open source and commercial applications.

All code associated with the project is available under the GNU General Public License (GPL).


General details on SoC are available at the the SoC FAQ.

Contacting Us

If you want to contact the folks involved in mentoring GSoC 2012, you can get ahold of us in a number of ways:

Note: Be sure to subscribe to the mailing list first, or your post will be rejected as spam.

Further Reading

Ideas Information

Common to all ideas

Skill set

  • Java
  • git (or another DVCS)
  • Eclipse (or another IDE)

OpenNMS is a very large Java-based application so knowledge of Java is intrinsic to working on the application. OpeNMS also makes heavy use of a very large number of 3rd party Java libraries but most importantly OpenNMS uses Spring, Hibernate and GWT for development. Knowledge of these is very beneficial as you will almost assuredly be exposed to these no matter what task or idea you decide to propose.

You may use the IDE of your choice but it is highly suggested that you use Eclipse as your IDE for the development of OpenNMS. This is mainly due to the fact that all of our documentation on setting up build environments is for Eclipse and the vast majority of OpenNMS developers use Eclipse. Your mentor will more than likely be using Eclipse so matching your mentor is a good thing.

OpenNMS uses Git for it's version control system. Your project will be hosted in a Gitorious repository which will clone OpenNMS. Understanding Git and the process for sharing this code with your mentor and other code reviews is very important.

Some tasks will explicitly call out necessary experience or skills but if in doubt please join our IRC channel or send an email to the mailing list.

Ideas List

Convert to xml or something more useful

  • Summary: Convert to xml or something more useful
  • Description: OpenNMS uses a .properties file today to generate graphs. This file is difficult to troubleshoot.
  • Technical Details: Create a way to select xml or .properties for generating graphs. Create xsd or jaxb class that covers all possible configurations in Create a conversion script to move graphs from .properties to xml format. Additional functionality to include multiple xml files would be nice to see as well. See bug 2165 and bug 850.
  • Difficulty: Difficult
  • Technical requirements: Java, rrdtool/jrobin, xml, jaxb
  • Mentor: Mike Huot

Create an OpenNMS Android App

  • Summary: Create an Android interface to the OpenNMS application.
  • Description: The OpenNMS project currently has an IOS application for viewing OpenNMS information. This idea would be to create an Android equivalent to this application. Separated into two stages you would add first the basic essential functionality such as viewing nodes, outages, alarms and being able to acknowledge alarms and add interfaces. The second stage would add more advanced functionality such as the ability the view and manipulate (zoom, manipulate timeframe) resource graphs, view events, view and edit asset information, etc.
  • Technical Details: See the IOS Client page for details on required features. See also the OpenNMS App in the iTunes App Store. Having your own Android device would be preferable but not entirely essential. You can use the device emulator for most development but ultimately it would be best to develop on an actual phone or pad.
  • Difficulty: Medium
  • Technical requirements: Java, Android SDK, Optimally an Android device.
  • Mentor: TBD

Modify the Homepage to Be A Portal

  • Summary: Convert the panels on the homepage to be dynamic and personalizable.
  • Description: Presently there are a number of UI panels on the OpenNMS home page. This task would separate them into "portlets" and allow user-level customization of them (location and size.) Time permitting you would create additional "portlets" for other pieces of functionality presently not on the homepage such as the Surveillance View, specific resource graphs, etc.
  • Technical Details: The page is presently written in JSP. The new page should be rewritten in GWT. It may be helpful to look at other GWT-based projects which provide similar functionality such as GWT Portlets.
  • Difficulty: Medium
  • Technical requirements: Java, GWT, Spring
  • Mentor: TBD

Replace Eventd Using New Technology

  • Summary: Replace Eventd using JMS via Camel and CXF while maintaining backward compatibility.
  • Description: Create a new Eventd daemon which functions as a messaging bus. Ensure that it is easy to expand with new functionality and retains a transport which is compatible with the classic eventd system so as to not break existing code. Document the process by which you would implement new EIPs into or out of OpenNMS.
  • Technical Details: This task will need to be written with full unit tests to ensure limited or no performance impact, full compatibility with the existing eventd transport and an example EIP. Optimally the project would also begin replacing the legacy eventd code with integrations to the with the new ESB.
  • Difficulty: Medium
  • Technical requirements: Java, Spring, JMS, Camel (or ServiceMix)
  • Mentor: TBD

Refactor the Web UI

  • Summary: The OpenNMS webUI is based on Java Server Pages and underlying Java servlets running on Jetty. While functional, it could use a lot of cleanup.
  • Description: This is not a rewrite, but instead we need someone to take a hard look at our current user interface and add some usability improvements, such as:
    • Insure tables have alternating (say white and grey) bars to make large tables easy to read.
    • General stylesheet improvements to make the webUI look cleaner, for example the Dashboard or when you look at an existing user's information.
    • Using AJAX or some other technology to help with pages that auto-refresh, like the alarms page, so that the whole page doesn't reload.
    • Creating "wizards" so that tasks like creating destination paths or notifications are easier to manage (i.e. when editing an existing notification, be able to jump to the last page to edit the text without having to go through the intermediate pages)
    • Rewrite the process for creating KSC reports.
  • Technical Details: TBD
  • Difficulty: Easy-to-Difficult (difficult scales dependent on how much the proposal attempts take accomplish)
  • Technical requirements: Java, Spring, GWT, JSP
  • Mentor: TBD

Reimplement Map Viewer and Editor

  • Summary: Reimplement the current map viewer/editor using HTML5 and GWT.
  • Description: The existing map viewer is using old SVG technology and is limited in its browser support. It is difficult to customize and improve. The new tool should be written using GWT and HTML5 Canvas (see GWT Canvas). You may also look at other similar projects being used for diagrams and alter them to fit the problem space such as GWT Links.
  • Technical Details: TBD
  • Difficulty: Difficult
  • Technical requirements: Java, GWT, HTML5, JavaScript
  • Mentor: TBD

Integration of Flume and ElasticSearch to analyze big log data

  • Summary: OpenNMS provide support for centralized logging of events over different protocols like SNMP, Syslog and native TCP. Integrate Flume and ElasticSearch (ES) to provide the data basis for a "OpenNMS Log Console"
  • Description: OpenNMS provide support for centralized logging of events over different protocols like SNMP, Syslog and native TCP. The incoming events will be normalized as OpenNMS-Events and will be stored in Postgres as RDBMS. An Administrator can now have access to logs for the whole network infrastructure on one place. In a extremely large networks it is complicated to process a lot of log in time and store them to a central database. Beside processing and storing a large amount of Logs, it is also complicated to analyze and navigate through all this data. To be able to store and analyze unlimited amounts of logs, it is necessary to have a architecture which can easily scale horizontally without modification of the OpenNMS application. With "Flume" exists a distributed and reliable service for collecting, aggregating and moving large amounts of log data which are stored in Hadoop's HDFS. With ElasticSearch exists a search engine based on Apache Lucene technology for indexing data. With OpenNMS capabilities of monitoring service degradation we can combine the technologies to provide a valuable data base for root cause analysis.
  • Technical Details: To be able to index the logs with ES it is necessary to extend Flume. Define mapping and indexes in ElasticSearch to query log data. Create a prototype for a OpenNMS Log Console in GWT to display and navigate through log events. Define integration points from log data to OpenNMS node and monitoring data especially outages, alarms and thresholds. The OpenNMS log console is test driven in Java with GWT.
  • Difficulty: Difficult
  • Technical requirements: Java, JUnit, ElasticSearch, Flume
  • Mentor: TBD

Integration of Cassandra Database as storage technology for time series data collected by OpenNMS Collectd

Replace RRD with Cassandra as storage for collected performance data

  • Summary: Integration of a Cassandra based database backend to enable OpenNMS to scale horizontally to be able to store a massive amount of performance data points.
  • Description: OpenNMS is able to collect and visualize performance data. OpenNMS provides a data collection daemon called collectd. Collectd is a distributable collect-deamon which supports multiple technologies i.e. SNMP, JMX, JMXMP, WMI, HTTP, JDBC, XML. The current implementation for storing datapoints is based on RRD-Tool wich is limited in several aspects. With RRD it is necessary to predefine the resolution for measuring performance metrics over the whole storage period. It is hard to change the resolution for collecting data or changing aggregation over time. Scaling to a massive amount of performance metrics is just possible by vertical scaling of the underlying I/O subsystems. Further it is not easy to provide data collection in a distributed environment across different locations. To tap the full potential of collectd a alternative storage backend is required. Due to the nature of the structure of performance data as flat timeseries-data, existing NoSQL systems are able to provide the required scalability, distributeability and flexibility. With integrating a noSQL storage based on Cassandra for time series data, it is possible to use the benefits for horizontally scaling I/O and storage capacity. Furthermore allows the usage of a data base a more flexible collection interval. On top of the noSQL Cassandra storage performans analysis and visualization is possible.
  • Technical Details: Creating a schema for collecting time series data in Cassandra. Integrate the Cassandra storage strategy in OpenNMS collectd. Implementing an API to get access to time series data from OpenNMS based on a resource identifier which combines node information stored in Postgres and collected performance metrics. The API should provide a mechanism to aggregate data for visualization. Stored data should have a life cycle. Create a visualization of time series data in the OpenNMS WebUI with GWT.
  • Difficulty: Difficult
  • Technical requirements: Java, JUnit, NoSQL,
  • Mentor: TBD

Implement rrdgraph emulation in javascript using d3.js

  • Summary: Provide a javascript library that would allow emulation of rrdgraph defined graphs using the d3 visualization library.
  • Description: For a long time OpenNMS has used rrdtool or Java equivalents to create graph images based for the display of performance metrics. OpenNMS would like to move to more interactive graphing using a library such as d3.js. Since there are already a large number of OpenNMS graphs defined it would be nice to be able to define a nice graph using the command line syntax but implement them using d3.js. Overtime this would allows us to augment the graphs with more interactive features.
  • Technical Details: Need to learn and understand graph definitions as defined by rrdtool and define a javascript library that will create graphs using these definitions and access to an AJAX service for retrieving the data. A REST interface will need to be defined that will allow this library the query the data from a set of RRDs that can be used in the graphs. Animation of new data coming in should also be considered.
  • Difficulty: Moderate
  • Technical requirements: Javascript, Java, AJAX, HTML, SVG, rrdtool
  • Mentor: Matt Brozowski

Converting OpenNMS from Castor to Jaxb for XML configuration file handling

  • Summary: The OpenNMS project started a migration from Castor to Jaxb for XML configuration file handling. The process of converting the code to Jaxb is not complete. This project would be to continue the work to get OpenNMS to use Jaxb entirely. Also the reloadability of the configuration files has to be improved.
  • Difficulty: Easy
  • Technical requirements: XML, Java
  • Mentor: TBD

Finish converting OpenNMS to use Hibernate


Many years ago the OpenNMS project started a migration to using Hibernate as an ORM for the application. The process of converting the legacy code to Hibernate is not complete (although all new code has been written to use DAOs). This project would be to continue the work to get OpenNMS to use Hibernate wherever possible. This will be divided into to parts. One is integration into the webui and the other is into the daemons(the rest of OpenNMS). The two students with these projects will have to coordinate if any dao's are needed.



Additional skills

  • Hibernate
  • SQL

Refactor opennms-services


OpenNMS used to have many of its components in one single project, opennms-services. In order to complete the move to Spring, some of the utility classes need to be moved out to corelib. Identifying, creating unit tests and moving these classes is key to this.



Additional skills

  • Spring
  • Common object-oriented patterns
  • Refactoring

Accepted Projects

GWT portlets

Mentor : Mike Huot

Student : Thirandu Munasinghe

Branch : remotes/origin/features/gsoc-dashboard