OpenNMS Update v2.2Jan 10, 2001, 07:09 (1 Talkback[s])
(Other stories by Shane O'Donnell)
Date: Wed, 10 Jan 2001 00:11:34 -0600 (CST)
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 To-Do list...
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. Oops.
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 three.
* 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 tool.
* 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 something.
* 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 week!)
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 RPMs.
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 lightweight GUI.
* 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 timeframe.
* 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 list.
* 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 peace.
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 us know.
Until then, here's where we'll be over the rest of the month:
* January 15th - RTP JUG, Raleigh, NC
For additional details on these appearances and others, check out the web site at http://www.opennms.org/engage/
Working on a Road Map
Working on a road map, a road map, a road map...
Despite all of our wonderful product documentation (and it
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 as new.
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. Anytime...
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 this:
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 well-taken.
Special Note to Fahad Dadahboy: You unsubscribe by reading the footer of EVERY STINKING EMAIL ON THE LIST and following directions.