From: announce-admin@opennms.org
To: <announce@opennms.org>
Date: Wed, 17 Jan 2001 20:01:47 -0500
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.

_______________________________________________
announce mailing list (announce@opennms.org)
To subscribe, unsubscribe, or change your list options, go to:
http://www.opennms.org/mailman/listinfo/announce