This Week in OpenNMS, Friday December 12th

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.

Share on Facebook

Comments are closed.