 |
| Coding on the Porch |
I've decided to do This Week in OpenNMS on Mondays, instead of Fridays, since it's more likely that people will be around to read it on Monday, and since then I don't have to furiously write under a deadline Friday afternoon when I could be sitting out on the porch, sipping drinks and relaxing. Or something.
Anyways, welcome to This (well, Last) Week in OpenNMS!
Project Updates
-
Stable: Current Release is 1.6.2
1.6.2 is still the current release, and while there are a few fixes pending since it's release, there are no immediate plans for a 1.6.3 yet.
-
Unstable: Current Release is 1.7.0
Trunk continues to move at a furious rate. We're still hoping to get 1.7.1 out soon. Stay tuned for updates on that. In the meantime, feel free to try the nightly snapshots (if it's not on a production system, of course).
-
Trunk: Build System Updates
Work has begun on refactoring our Maven build system. We've been trying to move a lot of things out of the main build, to speed up building and to componentize things that should be "external" dependencies. The new structure has been introduced, and we're looking at eventually moving all of our code into this structure:
-
core: OpenNMS core. This will include event handling, basic daemon support, and other support code needed by all of OpenNMS.
-
api: Interfaces and basic APIs
-
lib: "Library" code (the majority of the core code)
-
runtime: Runtime code, ie, things only needed in a running OpenNMS instance
-
web: Web application code common to all of OpenNMS
-
doc: Documentation
-
-
features: Any feature of OpenNMS that can be modularized, and isn't part of the Core. This will include most of the daemons (Notifd, Provisiond, etc.) Each feature gets it's own directory, and will have a similar structure to the core module.
-
extensions: Any feature of OpenNMS that does not need to be built by default for a basic running OpenNMS installation (ticketing integrations, etc.) Each extension gets it's own directory, and will have a similar structure to the core module.
-
lib: Support "library" code used by any part of OpenNMS, which can be a standalone package. The lib directory is not built by default, but instead deployed to the maven repository as they are updated as if they were individual projects. Examples include the service-registration framework (DNS-SD advertising), our version of JoeSNMP, and the SNMP strategies.
-
assemblies: Assemblies in maven describe how all of these various components get packaged up together. The plan is to make multiple assemblies for a minimal system, full install, and so on so you can choose how much OpenNMS you want when building from source. Having multiple assemblies will also make it easier to run just a portion of OpenNMS for development and testing.
-
-
Trunk: Provisiond
Provisiond is solidifying, the only major word to be done is support for the newSuspect events to fully replace Capsd's functionality. Lots of performance work has been going on in it as well, so it should be able to very quickly scan networks that took a long time under Capsd.
-
Trunk: RANCID
Antonio and Guglielmo have been working hard on the RANCID adapter. I'm told the RANCID map integration is very cool, but I haven't had a chance to check it out yet. It's in the latest snapshots.
-
Trunk: DNS Provisioning Adapter
I worked on Dave's provisioning adapter some, and got it working. Now whenever a node is added/updated/deleted, we can update a dynamic DNS server with the new hostname -> IP address mapping based on the node label in the provisioning group node configuration. It's a good example of how to make a provisioning adapter.
-
Trunk: UI Enhancements
Donald continues to make our UI more interactive, and handle large numbers of elements sanely. The node page is looking pretty sweet. 🙂
-
Trunk: Event Parameter Name Extraction
Jeff did a useful little feature to be able to use parameter names in %parm% expansions. See bug #3061 for details.
About the Inventory Scanner
Matt Raykowski has been working on a very cool feature in a branch called the inventory scanner. I asked him to send me a quick summary of what his goals are for the inventory scanner, and here's what he said:
Inventory Scanning is a protocol agnostic daemon tasked with collecting inventory and asset information from hosts through whichever means available to it through the coded scanners. At the present point in time only a WMI scanner exists but I plan on trying to get someone "onboard" to write a SNMP scanner and I plan on writing a telnet/ssh-based scanner that works similar to Expect.
Inventory Scanning saves inventory information in three layers: category, asset, property.
- Categories are high level classifications of assets. For example there may be a "Network Adapters" category. Categories are defined in the configuration and are not driven from host-based data.
- Assets are items of interest from hosts. Examples of assets would be "Broadcom 100MB Network Adapter."
- Properties are the individual components of information for a given asset. To continue our previous example you would have a manufacturer, serial number and assorted configuration information.
Categories are largerly going to be used for grouping and organization in the web representation of inventory information. All assets and properties will be idenfitied with a source, whether they're active and an effective date. During the process of scanning the scanner will collect all configured information from the host and pass that information to a persister which will go through the process of comparing the scanned asset information to the most effective version of the hosts configuration. It will add new properties and assets as they appear and remove (by setting the property or asset as deleted) any assets in the effective configuration set that are not in the scanned collection and were defined by that scanner source.
This last part is important: whatever is scanned and saved will have a history. When that history changes a UEI will be emitted for interested parties, potentially for notification. But the tracking of the source is important since now you can have multiple protocols maintaining asset information on a single host in addition to providing the user with limitless ability to manually add custom asset information.
Despite the fact that it can keep a history of inventory information in the database and the UI will have the ability to browse history and the user will have the ability to be notified on configuration change events this is not intended to be an enterprise grade replacement for other CMDB tools or inventory tools. It will not have the ability to send configuration changes to hosts, and at least in my incarnation no ability to differential comparisons between hosts or versions. Although this could be added on by some enterprising member of [The OpenNMS Group] or the community if someone decided this was a feature they desired.
Very cool stuff, Matt!
Upcoming Events
Note: April training has been pushed back to May.
-
March 14th, 2009: OpenNMS User Conference Europe 2009 will be held in Frankfurt am Main, Germany.
-
May 4th-8th, 2009: OpenNMS training will be available through The OpenNMS Group at the OpenNMS training facility in Pittsboro, NC.
-
June 14th-19th, 2009: OpenNMS Dev-Jam 2009, the annual OpenNMS developers conference, will be in Minneapolis-St. Paul this year.
If you have anything to add to the events list, or you wish to be a Dev-Jam sponsor, please let me know.
That's It!
That's it for this week. As always, questions, comments, non-sequiturs, gifts, and bribes are always welcome, feel free to e-mail me. And if you have a question about OpenNMS that you think would be a good topic in TWiO, please, let me know!
Share on Facebook
I heard rumors that reporting features would improve. Any updates or comments on that?
I’m not aware of any major reporting features, although there is someone who’s been working on Jasper integration. It’s not in a state where it’s releasable yet, though.