A rousing cheer for all of us who survived Y2K, both inbound and
outbound!

For those of you curious as to what happened to last week's
update, it simply fell prey to the holidays, as well as the stomach
flu, which laid several of us to waste last week. But I'm back in
black, I hit the sack, it's been so long, I'm glad to be back.

Anyway, a new year starts a new volume of Updates, so mark your
new calendars with a star on Tuesday, when you'll be able to read
the new and improved Y2K++ version of the Update, keeping abreast
of the project, and finding out all the inside scoop and latest
developments.

Mo' Better Install Doc Available:

Quoth Ben: "You asked for it, you got it"

The unruly mob has been clamoring for better installation
documentation for the non-RPM installs. Ben's first cut at this is
now available at:

The PDF version of this doc is not yet available, but then
again, form follows function. The HTML will have to do until we can
figure out why we are experiencing this FOP flop.

Ben's also asked me to note that he's also building, in all his
spare time, a Perl install script which will automate this process
for you. An early version of it exists today, but it does little
more than verify that Postgres exists, and we figure you can handle
that one on your own.

Give it a spin, and as always, if you have problems with the doc
or find errors, let us know, or better yet--update Bug #100 in
Bugzilla.

Coding Projects Underway:

* Servlets -- Actively working on building/tuning the
"extractors".

* SCM -- Pause/Resume functionality has been introduced for both
all SCM-controlled processes. This is now checked into the
development "trunk".

* SCM UI -- Now invokable only from the Administrator Main
panel, the SCM UI has also been set up to automatically refresh
itself every 30 seconds, and that interval is configurable.

* TCP Poller -- Mike has knocked out the "generic" poller, and
it has been committed to the development "trunk" of CVS. You can
check it out and give it a spin. Note that he's currently
configured it as a service to check the TCP "DayTime" service. You
can see the appropriate associated entries in defaults.xml,
CapsdPluginConf.xml, and scmconfig.xml.

* Maji Prelim Work -- Rick is active on the "events" mailing
list.

* Distributed Arc hitecture -- Continuing efforts, but we're
stealing resources to knock out some of the bug fixes and
functionality enhancements required by the current release. Time
frames will likely be sliding.

* Discovery -- There is now a property defined in the bluebird
properties file that allows you to determine a "sleep" period both
before discovery is started initially and following a completed
pass. Up to now, it started early and ran fast until you stopped
it. Improvement? We think so.

OpenNMS' CVS Check-In Procedures

Given the little period of confusion we had over the holidays
when the development "trunk" of the CVS tree would not build, I
decided now would be a good time to try to explain our check-in
procedures.

Currently, the strategy is simply this: Every member of the core
team has full check-in rights to the main branch as well as all
other branches of CVS. When code is written and tested by the
developer, it is checked into the appropriate point in the CVS
tree--as soon as it is deemed complete and functional by the
developer.

The developer is then charged with raising a flag to Weave so
that he's aware there is code that he needs to review. Weave will
then grab the code from CVS, do his magical incantations and the
naked code review dance, then dub it officially reviewed.

Why the commit before the review? This buys us two things: If
Weave gets backed up, the rest of the world can at least have
access to the code, rather than forcing Weave to become a
bottleneck in the process, and it provides us a means of code
control during the review process timeframe. Unfortunately, it also
opens us up to scenarios like last week where the main branch
wouldn't build, but in my mind, that's a small price to pay for the
benefits. Undoubtedly, those of you that were impacted found it
frustrating, but bear with us--and always remember, if you are
checking out of the main development "trunk", you are asking for
the bleeding edge, so don't be surprised if you get it.

Setting Expectations

Many of you have asked the question: "OK, you've released the
Testdrive release, but when will it be safe for me to download the
code and use it?"

That's a good question. For some of you, the bit-twiddling
propellor heads that understand what network management is about,
as well as our basic approaches, the time may very well be right
now. Then again, there are others of you that want to introduce
OpenNMS into head-to-head product evaluations with existing
commercial packages. For that, you'll probably want to wait.

Why wait, you ask? Well, a couple of reasons. First of all, the
Testdrive release was intended to provide folks with some code that
they could mess with, and in some cases, even use it to manage
networks. However, there are other aspects of the product that
render it considerably "sub-optimal". For example, up until last
week, our discovery process never rested. It would check your
defined range, and when done, start over again at the beginning.
This has now been addressed (and this code is in CVS), but it's
certainly not something you want happening constantly across your
network. Remember, in the grand scheme of things, SOMEBODY is
paying for every bit of traffic that gets carried, and if you like
that someone to continue to provide that service, you have to use
it with some responsibility. We're improving our approach to that,
and in turn, enabling our users to do that as well.

So remember, we aren't done yet. Don't expect the product to be.
If you have specific questions about functionality and when you
should start using the product, drop me an email, or better yet,
keep reading the documentation and Updates and give us a couple of
months to keep working. There's a lot of cool (and necessary) stuff
waiting in the wings!

A Visit from the Eventmeister

Rick Casey was in town over the holidays to talk about event
correlation. We got a chance to dig a little deeper into Doug's
Maji spec, but we certainly didn't have enough time to do
everything we wanted. Event correlation is a daunting task.

For those of you interested in helping out (or watching) on the
event correlation front, feel free to jump in on the events mailing
list. For those of you interested in how to get on the mailing
lists, go to the website. For those of you interested in going to
the website, just go already.http://www.opennms.org/

The Wish List

As this is a new year, the Wish List will become a new,
evolutionary tool to better express opportunities for you to jump
in and help. As an aside, contributions to the project have been
way up now that people can get the current release and at least
mess with it. Bug fixes are coming in at a respectable pace, as are
enhancement requests. Thanks for those of you participating. 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. Remember, documentation bugs
go to Bugzilla under Bug #100. Thanks.

* Got any creative applications for OpenNMS that we haven't
considered? Let us know!

Afterthoughts

OK. So it's a new year, and just like everybody else, I've made
my resolutions, and in most cases, I've already blown them off.
Here's my list for this year:

* Stop railing about major religious holidays. It doesn't appear
to go over well...

* Less talk, more rock.

* Spend less time watching infomercials and more time buying
those amazing products!

Advertiser Disclosure:
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.