December 2008 Archives

It's been a pretty busy week here in OpenNMS land.

Project Updates

  • Stable: RT Ticketing Plugin

    Jonathan got his RT ticketing updates finished, along with some OTRS cleanup. These have been merged back into trunk and the 1.6-testing branch, so should be ready pending a review, for the 1.6.2 release.

  • Stable: More Vendor Traps

    Jeff spent some time adding more SNMP collection, graphs, and trap events for a number of agents, including SNMP Informant and AIX.

  • Trunk: IfIndex Persistence

    Antonio committed a small change to the event and alarm persistence code to allow Trapd to extract IfIndex from varbinds if it is available.

  • Trunk: Provisioning

    We continued to focus on the new provisioning daemon and API, with a lot of design work and pair programming going on, especially on Matt's part. We all spent time this week breaking the work up into smaller chunks so we can get a better idea of what our progress is.

    Donald continued to work on the detector code, adding more detectors, tests, and cleanups to the existing code.

    I've been working on creating the model for the configuration that will drive provisioning, including changing the default plugin behavior, defining custom behaviors for determining which IP and SNMP interfaces will be managed (as well as what categories the nodes will be put into). I've been learning much about JAXB along the way, which gives us an alternative to all of the intermediate wrapper code we tend to have to put around our existing Castor model objects.

    David's been working on mocking up some code that will allow the provisioning system to automatically update a dynamic DNS server with information discovered during provisioning.

  • Trunk: WMI Support

    Matt Raykowski continued to work on putting some finishing touches on the WMI support. There's some more to do, but he's hoping to get a first drop of it released into trunk any day now.

  • Trunk: RANCID Integration

    Guglielmo committed the starts of what will become an implementation with RANCID, a tool for doing change management and configuration on Cisco devices.

    The first part wraps the existing (Tcl-based) RANCID tools with a web-services API. Next, we will be writing a plugin for the new provisioning API that can be called when managed node information changes.

  • Other: Laszlo Maps

    Matt Raykowski also spent some time in a branch he and Joed have been working on to create network topology maps using OpenLaszlo. It's not yet ready for integration into trunk, but a lot of good low-level work has been going on in that branch alongside the maps work.

  • Other: Web UI Work

    Rob Moore committed some updates to Matt's sandbox "expenses" application (a codebase to test out new technologies) which include a data grid and a sample query interface using JOSQL. We saw a preview of this at Dev-Jam this year, and it looks pretty sweet. Hopefully we can get it integrated into the OpenNMS web UI in the future.

Upcoming Events

Note: The OpenNMS Group is running a special until the end of the year. Sign up for basic support and get one basic training voucher, sign up for enterprise support (including upgrading from basic) and get a combined basic/advanced training voucher. See Tarus's "Forget TARP, Take COVER" post for details.

If you have anything to add to the events list, please let me know.

'Zat You, Santa Claus?

That's it for this week.

The OpenNMS Group is off from Christmas to the new year, so things will probably be quiet next week. I want to wish you all a happy non-denominational, non-specific, non-offensive, winter solstice time celebration day!

As always, feel free to drop a comment my way if you have any suggestions, love- or hate-mail, or anything at all.

So far the response has been positive to TWiO, so it's time again for another chapter.

Project Updates

  • Stable: Ticketing Updates

    Jonathan Sartin worked more on the OpenNMS trouble-ticketing API, finishing up a change to allow ticketer plugins to be able to raise exceptions when errors occur. In addition, he resurrected work on an RT (Request Tracker) ticketer plugin. Both will be merged to the 1.6 branch when they're ready.

  • Stable: Bug Fixes

    I spent a little time this week cleaning up some bugs, mostly exceptions, simple bugfixes, and other minor changes.

  • Stable: Windows Updates

    Bobby Krupczak was kind enough to lend a Win64 machine with Visual Studio so I could get 64-bit binaries built. They are available now on SourceForge. (Copy the jicmp and msvcr90 DLLs to your system directory, don't forget to rename them to remove the -win64 bit.)

    In the process of working on that, a reasonably serious bug was found in the JICMP libraries on Windows. Windows passes around HANDLEs instead of file descriptors for the purposes of file I/O (and socket I/O). We were treating them as if they were normal file handles (ie, integers), which just happened to work on Win32, not because it was correct, but because we didn't try to access the filehandle from Java directly. :) The code has now been cleaned up to treat socket operations on HANDLEs (well, SOCKETs) properly on Windows, and the new DLLs in the JICMP 1.0.9 binary release contain these changes (win32 and amd64).

    Additionally, it was determined that Windows XP, at least, is pickier about reading from raw sockets than other platforms, and requires that at least one packet is sent out the socket before reading any in (even though we're just listening for any ICMP packets on the raw socket, so it shouldn't really matter). This is fixed in the jicmp.jar in the 1.0.9 distribution; until 1.6.2 comes out, it is recommended you copy this jar over the one included in $OPENNMS_HOME/lib if you are running on Windows.

  • Trunk: More Work on the New Provisioner

    Donald continued implementing "detectors", the equivalent of Capsd's protocol plugins, including a new asynchronous API which will allow us to interact with services at a much more granular level.

    Matt has proposed we use more agile development practices, and towards that goal, he started working on a document describing the current desired featureset of the provisioner. We've broken it up into chunks which will then be used to do code sprints so we can do a better job of divvying up the work. We're working on going through and cleaning up the documentation and hopefully we'll get it into the wiki soon.

  • Trunk: Refactoring Maven (Services)

    Right now, one of the biggest chunks of code in our source tree is "opennms-services". It's kind of a dumping-ground of all of the high-level code that isn't webapp code, and it's a bit unweildy. I've started a branch to attempt to refactor at least some of it into smaller chunks (splitting out capsd, collectd, config, eventd, mock, notifd, poller, threshd, trapd, xmlrpcd, and so on). Work will be ongoing, but hopefully eventually we'll have things a bit more manageable.

  • (Almost) Trunk: WMI Support

    Matt Raykowski has been finishing up work on his WMI (Windows Management Instrumentation) monitor and collector and we hope to be merging it into trunk in the near future. There are just a few more finishing touches to put on it, and then it will be ready for inclusion in the future 1.8 release.

Upcoming Events

(Or, as Tarus calls it, Git Yer Learnin' On.)

If you have anything to add to the events list, please let me know.

Development: A Brief Interlude

It's time for a little aside on some of the tools we use for development.

Maven is an awesome tool, but with a large project like OpenNMS, checking repositories and other things are actually a significant drag on the build process. To help alleviate this (and to speed up building and sharing artifacts on our Bamboo continuous-integration server) we set up a Nexus proxy at the office. It worked so well, I set one up at home too. =)

If you'd like to set up your own, I've documented what we did on the OpenNMS wiki. Feel free to update it (and/or ask questions) if you run into any issues.

And on the subject of Bamboo, I realized I haven't yet publicly thanked Atlassian for their generosity. They've generally been very generous to open-source projects, offering free licenses for their tools (continuous integration, bug tracking, etc.) OpenNMS has a very large build, and it can take a long time to work it's way through the continuous-integration process even with a fast machine. They were kind enough to extend our open-source license to allow for more than the usual number of agents, and we're now burning rubber with our entire set of classroom machines acting as build agents. No longer do we have huge queues of waiting builds, we get very timely Jabber notices when we break the build. Hm... maybe that's not such a good thing after all. ;)

Anyways, thanks again to Atlassian for the license upgrade, it's working great!

That's It for This Week

That's it for now. I hope you're enjoying these updates. If you have any questions or comments, or if you've done something cool with OpenNMS that you'd like included, please let me know.

I was recently remembering fondly the oldskool "OpenNMS Updates" that Shane O'Donnell used to do, and I thought I'd take a crack at reviving the tradition. So, without further ado...

Project Updates

  • Stable: Current Release: 1.6.1

    OpenNMS 1.6.1 seems to be holding up without any huge bugs reported. There are no immediate plans for a 1.6.2 release but I would expect we'll look into doing one in a month or so just to roll up any bugfixes that have happened, if nothing else.

  • Stable: Configuration Tweaks

    David did some configuration changes that will be in a future 1.6 release which automatically roll up SNMP LinkUp and LinkDown traps into an alarm. Also, Jeff added a bunch of IETF and vendor MIB data collection and graphs to the 1.6 branch.

  • Trunk: Provisiond

    Development is still churning along in trunk, with the focus on the Capsd rewrite. Since this is the first (of hopefully many) TWiO, I will go into a bit more depth.

    OpenNMS has always been written with scalability in the forefront of our minds, but JVM technology and development methodologies have moved a lot since we first started the project 9 years ago. Since the OpenNMS 1.2 series, and even a bit before, many of the subsystems of OpenNMS have been tweaked, cleaned up, and even rewritten for performance and other reasons. One of the things that's needed attention for quite some time is Capsd, the part of OpenNMS that figures out what devices are on your network, and what those devices' capabilities are (hence, Capsd).

    Matt Brozowski has been working on a complete replacement, called Provisiond. One of the benefits of the OpenNMS architecture is that it's event-driven structure with distinct daemons for different subsystems makes it easy to make new implementations without breaking existing things. Thus, Provisiond will be installed (disabled, by default) alongside Capsd in 1.8, and in 1.10 (or 2.0), it will become the default capabilities scanner, with Capsd deprecated but not yet removed.

    The Provisiond architecture is such that a very robust threading model has been introduced to allow scanning huge numbers of resources in a very efficient manner, and the API has been written to make it very simple to implement new "detectors" which detect services and resources.

    Eventually this new architecture can (and should) be extended to polling/monitoring and data collection, but... one thing at a time. ;)

    Anyways, Matt has been rockin' the Java working on Provisiond, and I've been pairing with him off and on. I really like the way this code is shaping up. Donald in the meantime has been making tons of detectors so we can cover the large range of services we already detect with Capsd.

  • Trunk: Mobile UI

    Alexander Finger started work on a simple mobile UI that gives you the outages summary on a single page (at least on my iPhone <g>).

    OpenNMS Mobile UI

Upcoming Events

If you have anything to add to the events list, please let me know.

From the Discussion Lists - Cartographer

[original thread]

Bobby Krupczak has created a tool called Cartographer which "implements a novel approach to managing distributed systems by automatically discovering and tracking the relationships between its component systems and applications." In addition to the Cartographer protocol (XMP), software, and agent, he has written a collector plugin for OpenNMS which allows the collection and graphing of Cartographer XMP data. Very cool!

Hopefully soon we will get the collector integrated into OpenNMS proper and a future release (1.6 if it's not too invasive, or at the latest, 1.8).

That's It!

So that's it for this week. Let me know if you think this is a useful thing for me to do, if there's anything you'd like me to talk about that's missing, or, well, if you have any comments at all. Until next week...