Linux Today: Linux News On Internet Time.

OpenNMS Update v2.1

Jan 02, 2001, 22:49 (0 Talkback[s])
(Other stories by Shane O'Donnell)

Date: Tue, 2 Jan 2001 16:25:59 -0600 (CST)
From: announce-admin@opennms.org
To: announce@www.opennms.org
Subject: [opennms-announce] OpenNMS Update v2.1

OpenNMS Update
Vol 2, Issue 1
Jan. 2, 2001
   In this week's installment...

     * Project Status

          + Happy New Year!

          + Mo' Better Install Doc Available

          + Coding Projects Underway

     * OpenNMS' CVS Check-In Procedures

     * Setting Expectations

     * A Visit from the Eventmeister

     * The Wish List

Project Status

Happy New Year!:

A rousing cheer for all of us who survived Y2K, both inbound and outbound!

For those of you curious as to what happened to last week's update, it simply fell prey to the holidays, as well as the stomach flu, which laid several of us to waste last week. But I'm back in black, I hit the sack, it's been so long, I'm glad to be back.

Anyway, a new year starts a new volume of Updates, so mark your new calendars with a star on Tuesday, when you'll be able to read the new and improved Y2K++ version of the Update, keeping abreast of the project, and finding out all the inside scoop and latest developments.

Mo' Better Install Doc Available:

Quoth Ben: "You asked for it, you got it"

The unruly mob has been clamoring for better installation documentation for the non-RPM installs. Ben's first cut at this is now available at:


The PDF version of this doc is not yet available, but then again, form follows function. The HTML will have to do until we can figure out why we are experiencing this FOP flop.

Ben's also asked me to note that he's also building, in all his spare time, a Perl install script which will automate this process for you. An early version of it exists today, but it does little more than verify that Postgres exists, and we figure you can handle that one on your own.

Give it a spin, and as always, if you have problems with the doc or find errors, let us know, or better yet--update Bug #100 in Bugzilla.

Coding Projects Underway:

* Servlets -- Actively working on building/tuning the "extractors".

* SCM -- Pause/Resume functionality has been introduced for both all SCM-controlled processes. This is now checked into the development "trunk".

* SCM UI -- Now invokable only from the Administrator Main panel, the SCM UI has also been set up to automatically refresh itself every 30 seconds, and that interval is configurable.

* TCP Poller -- Mike has knocked out the "generic" poller, and it has been committed to the development "trunk" of CVS. You can check it out and give it a spin. Note that he's currently configured it as a service to check the TCP "DayTime" service. You can see the appropriate associated entries in defaults.xml, CapsdPluginConf.xml, and scmconfig.xml.

* Maji Prelim Work -- Rick is active on the "events" mailing list.

* Distributed Arc hitecture -- Continuing efforts, but we're stealing resources to knock out some of the bug fixes and functionality enhancements required by the current release. Time frames will likely be sliding.

* Discovery -- There is now a property defined in the bluebird properties file that allows you to determine a "sleep" period both before discovery is started initially and following a completed pass. Up to now, it started early and ran fast until you stopped it. Improvement? We think so.

OpenNMS' CVS Check-In Procedures

Given the little period of confusion we had over the holidays when the development "trunk" of the CVS tree would not build, I decided now would be a good time to try to explain our check-in procedures.

Currently, the strategy is simply this: Every member of the core team has full check-in rights to the main branch as well as all other branches of CVS. When code is written and tested by the developer, it is checked into the appropriate point in the CVS tree--as soon as it is deemed complete and functional by the developer.

The developer is then charged with raising a flag to Weave so that he's aware there is code that he needs to review. Weave will then grab the code from CVS, do his magical incantations and the naked code review dance, then dub it officially reviewed.

Why the commit before the review? This buys us two things: If Weave gets backed up, the rest of the world can at least have access to the code, rather than forcing Weave to become a bottleneck in the process, and it provides us a means of code control during the review process timeframe. Unfortunately, it also opens us up to scenarios like last week where the main branch wouldn't build, but in my mind, that's a small price to pay for the benefits. Undoubtedly, those of you that were impacted found it frustrating, but bear with us--and always remember, if you are checking out of the main development "trunk", you are asking for the bleeding edge, so don't be surprised if you get it.

Setting Expectations

Many of you have asked the question: "OK, you've released the Testdrive release, but when will it be safe for me to download the code and use it?"

That's a good question. For some of you, the bit-twiddling propellor heads that understand what network management is about, as well as our basic approaches, the time may very well be right now. Then again, there are others of you that want to introduce OpenNMS into head-to-head product evaluations with existing commercial packages. For that, you'll probably want to wait.

Why wait, you ask? Well, a couple of reasons. First of all, the Testdrive release was intended to provide folks with some code that they could mess with, and in some cases, even use it to manage networks. However, there are other aspects of the product that render it considerably "sub-optimal". For example, up until last week, our discovery process never rested. It would check your defined range, and when done, start over again at the beginning. This has now been addressed (and this code is in CVS), but it's certainly not something you want happening constantly across your network. Remember, in the grand scheme of things, SOMEBODY is paying for every bit of traffic that gets carried, and if you like that someone to continue to provide that service, you have to use it with some responsibility. We're improving our approach to that, and in turn, enabling our users to do that as well.

So remember, we aren't done yet. Don't expect the product to be. If you have specific questions about functionality and when you should start using the product, drop me an email, or better yet, keep reading the documentation and Updates and give us a couple of months to keep working. There's a lot of cool (and necessary) stuff waiting in the wings!

A Visit from the Eventmeister

Rick Casey was in town over the holidays to talk about event correlation. We got a chance to dig a little deeper into Doug's Maji spec, but we certainly didn't have enough time to do everything we wanted. Event correlation is a daunting task.

For those of you interested in helping out (or watching) on the event correlation front, feel free to jump in on the events mailing list. For those of you interested in how to get on the mailing lists, go to the website. For those of you interested in going to the website, just go already.

The Wish List

As this is a new year, the Wish List will become a new, evolutionary tool to better express opportunities for you to jump in and help. As an aside, contributions to the project have been way up now that people can get the current release and at least mess with it. Bug fixes are coming in at a respectable pace, as are enhancement requests. Thanks for those of you participating. Now, on with the list...

* Now that we have a "generic" TCP Poller, we could use some help in building some configurations to test services that you may be concerned with. For example, is LDAP do-able? How about applications like Peoplesoft, SAP, Baan? Remember, you can deploy multiple of these pollers against multiple ports.

* Testing on new, exciting platforms is always appreciated. Somebody want to mess with the Cygwin port of Postgres to NT and see where we stand over there?

* Any additional help we can get proving our documentation either right or wrong is appreciated. Remember, documentation bugs go to Bugzilla under Bug #100. Thanks.

* Got any creative applications for OpenNMS that we haven't considered? Let us know!


OK. So it's a new year, and just like everybody else, I've made my resolutions, and in most cases, I've already blown them off. Here's my list for this year:

* Stop railing about major religious holidays. It doesn't appear to go over well...

* Less talk, more rock.

* Spend less time watching infomercials and more time buying those amazing products!

* Write a book.

* Don't drink any more or any less, but drink smarter.

* Go to Germany, but for more than two days this time

* Trade in my Mork suspenders for a Fonzie jacket.

* Avoid the flu.

* Promote world peace through open source!

Happy New Year and thanks for hanging out!
Shane O.

Shane O'Donnell