OpenNMS Update v2.3Jan 18, 2001, 06:26 (1 Talkback[s])
(Other stories by Shane O'Donnell)
Date: Wed, 17 Jan 2001 20:01:47 -0500
Vol 2 Issue 3
January 16, 2001
In this week's installment... * Project Status + Project Strategy and Roadmap + Team Membership Changes + Coding Projects Underway * Philly and New York * Notification Clarification * The Wish List
Project Strategy and Roadmap:
We've been doing some research, and this is what we are hearing...
The Enterprise class users of OpenNMS are pleased with the early progress and give us lots of nice pats on the back for building an open source tool, focusing on their needs, yadda yadda yadda.
What we are also hearing--consistently--from management at these sites is that while they are intellectually interested, they will not be interested in actually using the product until it has had time to mature. The timeframe for that maturation process that they describe is anywhere from 2-10 years--much long than we are prepared to wait.
Who cares, you say. Well, I do. Until we have a product that is up and running in commercial environments, I don't feel that we can consider ourselves successful. And unfortunately, up until now (or at least very recently), our development schedule was aimed directly and building that Enterprise class tool, knowing that we could address the needs of the small to medium sized networks in the process. So what's the resolution to this dilemma?
We've talked this over at great length internally and we've gotten great feedback from you--the OpenNMS community--that we find supports this. We have decided to change our strategy so that rather than focusing on the enterprise and building an incidental tool for the small to mid-sized business (SMB) on the way, instead, we'll focus on the needs of the SMB within our architecture, so we can grow once we've built a solid core product.
The new approach is simply this: Maintain the current architectural direction (e.g., Master Station, Distributed Poller), but focus development efforts immediately on the pieces that can get us maximum usage sooner than later. You've proven to us that the troubleshooting, bug fixing, feature enhancement, and porting support we so desperately need is available to us, but only if we continue to provide a solid base product.
The immediate impacts of this decision are as follows:
* We split the development calendar to deliver parts of the product that will allow functionality in small to mid-size networks earlier (0-9 months) and the enterprise-only functionality after that (9-18 months).
* We target an improved performance of the base platform before moving it into a distributed architecture.
* Integration or addition of key functionalities becomes paramount, including integration with performance analysis tools (a la MRTG, RRDTool, etc.), notification tools (a la qpage, beepage, etc.), rudimentary event correlation, and enhanced event handling.
* More focus on ease of installation issues for the "single box solution".
* Effectively, build a great one-box management tool with a solid distributed architecture direction, rather than end up with a solid solution that is way ahead of its time (from an Enterprise perspective).
* We're actively working to include these features in the next release, 0.6.0, which will include at least an SNMP poller, a new rule builder, a new DP configuration panel, and hopefully, a tuned SCM. 0.6.0 is targeted for 2/1/01 and I'm still working on the road map.
I hope this is well received. I believe this makes a lot of sense for everyone involved. The "typical user" (if such a thing exists), gets a platform sooner--the enterprise gets a proven platform in the timeframe they are expecting it. If you are in a large enterprise that doesn't share this view (and is willing to put its money where its mouth is), drop us a line. For the cost of only a few developers, we could do parallel development to both our short and long term goals.
Feel free to express your messages of support, encouragement, and love to the [discuss] list.
Team Membership Changes:
Ladies and Gentlemen! Please consult your scorecards and make the following substition:
It's been a week of mixed blessings around the OpenNMS offices. Vishwa (better known as "Doctor DPConfigF") has left us to spend a little time in India. Happy trails, safe travels, and thanks for all your contributions! And no, this wasn't the "blessings" part...
The upside is that Larry Karnowski, formerly of MCI/WorldCom fame, has now joined us on a full-time basis. Larry has taken on the mantle of "owning" our user interfaces, making sure things are consistent, and that we have the tools we need on this front as well.
So a big welcome to Larry and alas, poor Vishwa, I knew thee well. Good Luck!
Coding Projects Underway:
* Solaris Port of ICMPD and Postgres Procedures -- Big thanks to Harald G. for his contributions here. icmpd for Solaris is in CVS and will be rolled into the next release.
* SNMP Poller/Data Collection -- Our approach here is to build an SNMP Data Collector that can populate a performance database. Our config file needs some help. See the Wish List for details.
* 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 making some progress and showing some marked improvements. Currently have reduced the total number of JVMs by 4, and there's still some work to go.
* User Interfaces -- Actively working on building/tuning the "extractors". This will be the data source we'll make available to anyone wanting a lightweight user interface.
* SCM -- Continuing to test for reliability, run time, and working through some JSDT issues.
* 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 -- All work here is on hold until later this year.
* New Rule Builder -- In testing.
Philly and New York
As you can see from the bullets that follow, we've managed to lighten our presentation load considerably. This also means that if you are looking for a presenter for your LUG, JUG, or other related interest group, it's easier than ever for you to schedule us in now for the next year. Interested? I thought so. Contact Luke (or as we say in the Latin, Flipius-Flopius) at email@example.com.
Earlier this week, I gota chance to meet with some of the local JUGs (no, not the magazine) and have gotten some good feedback, learned a little something about Sun's JAXB, and received some interest in the effort.
Next up on our tour spree...
* January 30th - University City JUG, Philadelphia, PA
* January 30-February 2 - Wandering the halls at LinuxWorldExpo-New York. Want to hook up? We're open most of the time this week, especially if you're in the Tri-State area.
* February 15th - Utah JUG, Salt Lake City, UT
For additional details on these appearances and others, check out the web site at http://www.opennms.org/sections/opennms/events (NOTE: New URL)
Judging from the traffic following my question on notification in last week's update, two facts are apparent:
* There is concern about HOW we may be integrating notification services into OpenNMS.
* I am an absolute idiot.
Following that discussion, here's my current status. Argue it if you like (you haven't hesitated so far), but here it is:
Notification is an important part of a comprehensive problem identification, isolation, and resolution process. However, it needn't be coupled into the base identification platform. That's fair. But then again, we've done almost nothing that ties any piece of OpenNMS in lock step to another. Some are dependencies, but our basic design tenet is modularity. Notification is being designed to be invoked as a configurable automated action, via the tag in the eventconf.xml. Integration at the OS level is just about as loosely coupled as you can get, and if you don't like our stuff and want to replace it with Telamon's stuff (or anybody else's), knock yourself out. We've simply identified a need, and want to fill it.
The jury is still out on the second item.
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...
* Our SNMP Data Collector will rely on a configuration file, DataCollection.xml (or something like that). This file will map what SNMP OIDs we should pull from a device with a given SysOID. Now the question is, "What should we pull?" Recommendations? Tips? I figure we'll pre-populate some canned collections for Cisco routers, Bay routers, and whatever else can be contributed. All ideas are appreciated, and especially ideas that come back in the format of the DataCollection.xml file (available at: http://www.opennms.org/cgi-bin/cvsweb.cgi/data/common/conf/DataCol lection.xml )
* 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...
Lots of long days this week. My brain is not fully functional.
Anyway, Doug Stevenson passed along a great reference for the XML-types amongst us: http://searchxmlresources.techtarget.com
Ben says: Anyone with masochistic tendencies, a taste for adventure, and a significant amount of RAM should try the install script, install.pl. We can only test installing this thing so many times on the same box before results are, shall we say, tainted. Post your responses to the [discuss] list or to Ben directly at (you guessed) firstname.lastname@example.org.
And I have relatively little left to say. So I shant.