From: announce-admin@opennms.org
To: announce@www.opennms.org
Date: Wed, 10 Jan 2001 00:11:34 -0600 (CST)
Subject: [opennms-announce] OpenNMS Update v2.2

================
 OpenNMS Update
================
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
       

==============
Project Status
==============
   
     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
     * January 16th - Charlotte JUG, Charlotte, NC
     * January 30th - University City JUG, Salt Lake City, UT
       
   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 is
   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 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...
       

=============
Afterthoughts
=============
   
   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.

Later,

Shane O.
========
Shane O'Donnell
OpenNMS.org
shaneo@opennms.org
==================
_______________________________________________
announce mailing list (announce@opennms.org)
To subscribe, unsubscribe, or change your list options, go to:
http://www.opennms.org/mailman/listinfo/announce