Date: Wed, 10 Jan 2001 00:11:34 -0600 (CST)
Subject: [opennms-announce] OpenNMS Update v2.2
Vol 2., Issue 2
Jan. 9, 2001
In this week's installment...
* Project Status
+ New Development Targets
+ New Features in CVS
+ Coding Projects Underway
* Let the Road Shows Commence
* Working on a Road Map
* Change to Documentation Bug Reporting
* The Wish List
New Development Targets:
Another week, another few features, a few less things on the
We've been busily building out some of the pieces that we've
needed to solidify the 0.4.x series of releases. Our frantic pace
of adding and replacing functionality has been betrayed by a couple
of times when the development trunk of CVS wouldn't build.
Rest assured that we don't like hearing that CVS won't build
almost as much (if not AS much) as you are frustrated by the fact
that it won't. We've taken some steps internally to make sure it
doesn't happen again, and without mentioning names, we asked Mike
not to break the build anymore. He begrudgingly agreed.
As alluded to on the [discuss] list late last week, we've
shifted some of our development cycles to better address the more
immediate needs of the product, which is beginning to take on a
life of its own. The big things that we're working on right now
include (in no particular order):
* Reducing the impact on system resources. Weave's working on
getting the overall footprint of the application down. Rumor on the
inside has him surprisingly close to finished building a
configurable environment that will allow you to determine how many
JVMs it takes to run OpenNMS? A one. A two-oo. A three. Crunch. A
* An SNMP Poller/Data Collector. Something with a little bit of
intelligence to help people get out of the environment where one
tool polls the router for SNMP performance statistics, another
polls for "smart polling/correlation" purposes, and another pings
it every 5 minutes because it feels like it needs to. Ours takes a
somewhat more logical approach, but I'll save the juicy details for
later. This will soon feed a performance graphing/trend analysis
* Rudimentary Event Correlation. This includes a hook in eventd
to watch for certain events and either A) suppress duplicate events
or B) watch for events that cancel out the original events. We're
referring to these internally as "event singlification" and "event
cancellation". These are both simple approaches to buy us time
until we can get Maji assembled.
* Notification Engine. This is the part you either love or
hate--the part that pages you when something goes down. We're
trying desperately to find an existing open source tool that does
real notification services, such as allowing for schedules,
escalations, clearing notifications, etc., and we're not having a
lot of luck. In lieu of finding one, we'll be building
* Lighter-Weight User Interface. Something not quite so hulking
(or feature-rich) as the Real-Time Console. Just a quick
one-stop-shop for the critical information, probably proffered via
web page. If you've got ideas as to what you'd like to see, forward
them to our newest team member (more details on that next
New Features in CVS:
I've already let the cat out of the bag on some of these
already, but I figured I've give you a rundown on some of the
recent successes we've had, and some of the features that are soon
to be included in another major release (0.6.0?), hopefully by the
end of the month.
First off, Jason has been busily consolidating the code between
two parallel instances of "rule builders". He's also converted them
from using JCup and JLex to using SableCC. I haven't dug into it at
all, but he's become a SableCC convert, and I don't think it's just
because of the name similarity to a WWF female fave...
Vishwa has finished an 80% re-write of the "Configure
Distributed Pollers" window and underlying functionality. It had
been through to many hands and was too inconsistent to be readily
maintainable, so he played cleanup guy for the past couple of
weeks. You da man, Vishwa. Thanks for your contributions!
Mike's contributions, when they build, are awesome. He's added
the basics for an SNMP poller that plugs into the scheduler
framework. while this is a VERY early release, there is some stuff
in CVS to play around with. And much more to come.
And last but not least, we can't forget Ben's new install.pl
script. We're hoping to roll this into the next major RPM build in
place of the embedded post-install scripts (actually, we'll invoke
this from a much smaller post-install script). This allows us to
share the "automatic" installation with those that opt to not use
Anyway, all of this (and more!) is in CVS as we speak. Use at
your leisure, and at your own risk. And keep watching for a major
release coming sometime around the end of the month!
Coding Projects Underway:
* Event DTD -- Some oversights in the first version have us
revisiting this sooner than later. The DTD work is minimal. The
number of places that will be impacted are maximal.
* Tuning -- Weave is trying to minimize our impact on system
resources. He should have A to 440hz in no time...
* Servlets -- Actively working on building/tuning the
"extractors". Jacinta's also working on some stuff to support the
* SCM -- Pause/Resume functionality has been introduced for both
all SCM-controlled processes. This is now checked into the
development "trunk". Testing continues.
* SCM UI -- Still having some of the known issues with JSDT. We
should be able to address those in the early February
* TCP Poller -- Still waiting for some of the creative
configurations that I know you all are capable of...
* Maji Prelim Work -- Rick is active on the "events" mailing
* Distributed Architecture -- Most of this effort is currently
coming from community contributions.
* New Rule Builder -- Due to some bad decisions early on, we
were maintaining to separate codebases for the two rule builders.
We've now merged them. If any one here knows why these two
codebases should not be joined, speak now or forever hold your
Let the Road Shows Commence
While we slowed down a little bit at the end of the year, we are
back for more in 2001. If you are aware of a user group, conference
trade show, or other technical forum that might benefit from some
good ol', down home, open source network management religion, let
Until then, here's where we'll be over the rest of the
* January 15th - RTP JUG, Raleigh, NC
* January 16th - Charlotte JUG, Charlotte, NC
* January 30th - University City JUG, Salt Lake City, UT
Despite all of our wonderful product documentation (and it
wonderful), I've fallen down on the job of putting together a good,
consistent project road map. We had one before that led us to a
somewhat different target than we are shooting for now, and I
haven't gotten it updated. My bad.
I promise to focus on this soon, but I'd appreciate some input
in the interim as to the best method by which to lay this out. Any
and all ideas are appreciated.
Change to Documentation Bug Reporting
In an effort to avoid a lot of bugs that were for small
typographical errors in the documentation, we asked that all bugs
get logged to Bug #100. We think we're out of the woods on the
little stuff now, so henceforth, please post all documentation bugs
We'll wrestle them from there.
The Wish List
First, a big thanks to everyone that's actively working with and
trying out the product. There are a lot of cool innovations
committed recently that you'll want to take a look at as well.
Again, our thanks to the testers!
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. Thanks.
* Got any creative applications for OpenNMS that we haven't
considered? Let us know!
* Anybody up for a security analysis of OpenNMS? We know we've
got a lot of holes, but we'd rather have most of them identified
before we start trying to plug them. Any security folks that are
playing along, feel free to chime in here. Anytime, now. Go on.
I'm tired. It's late. I'm not thinking well. But I did get an
email earlier this week that I'd like to discuss "out loud" here. A
very well-meaning and well-presented argument against including
notification as part of the base product was presented by a friend
whose opinion on NOC design, work flows, and processes I respect.
Without uncovering his identity (yeah, he's a guy. That limits it
to 98% of the mailing list...), the argument goes something like
OpenNMS has been building a tool that has been apparently
focused on the generic area of Problem Detection. Notification
falls squarely in the Problem Management camp. While a good Problem
Detection tool has an interface to Problem Management tools, to
build notification into OpenNMS violates this boundary and while
addressing short term needs, may become an inhibitor to addressing
the real needs of overall service management down the road.
What do you think? My initial take is that while the boundaries
between Detection and Management tools work well in academic
discussions and larger organizations, most people are concerned
with tactical deployments today. And while I'd rather build the
right tool for tomorrow than the right tool for today, I don't
think that our plans to integrate notification capabilities will be
something we can't turn off if necessary. Admittedly, having them
there at all will be encouraging people to break the rules and
potentially screw them over as they grow their business and in turn
try to grow their management solution, but given the risk factors
involved with network management deployment in most shops anyway
(turnover, training, funding, stock market collapse, VC funding
going away, etc.), I think this risk is minimal.
Feel free to talk this one over on the [discuss] list.
Note to Original Author of this Argument: Thanks for the note
and sorry for hashing this out in public. But your points are
Special Note to Fahad Dadahboy: You unsubscribe by reading the
footer of EVERY STINKING EMAIL ON THE LIST and following
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.