Date: Wed, 17 Jan 2001 20:01:47 -0500
From: announce-admin@opennms.org
To: announce@opennms.org
Subject: [opennms-announce] OpenNMS Update v2.3
OpenNMS Update
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 Status
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 luke@opennms.org.
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)
Notification Clarification
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…
Afterthoughts
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) ben@opennms.org.
And I have relatively little left to say. So I shant.