Configuration Packs

Goal

Make it possible to extend the base configuration by installing vendor specific “configuration packs”.

These should be easy to install, upgrade, remove and at minimum it should be possible to extend:

  • Data Collection
    • SNMP
    • JDBC
  • Poller
  • Events (how to handler ordering?)
  • Graph definitions
  • Notification templates

Ideally, it would be possible to install a “config pack” on a running OpenNMS instance, re-scan a node, and get all the functionality provided by the pack.

Folks

  • Jesse White

Story

  • Jesse provisions a node, some basic services are detected
  • Jesse drops a .jar into $OPENNMS_HOME/deploy/
  • Jesse re-provisions an existing node, new services are detected
    • New graphs are available
      • New events/alarms are available
    • New custom detector, monitor and collector implemenations are available
    • New notifications strategies are available

Proof of Concept

In the features/extend-the-config we have introduced a new ConfigReloadContainer (an alternative to the FileReloadContainer) that supports configuration extensions by providers in the service registry:

  • When configured with an extension type, the ConfigReloadContainer will listen for ConfigurationProvider service registrations that expose a byte stream for the given extension type.
  • Merging of the configuration files is then delegated to the DAO implementation.

Next steps

There are currently several different ways of configuring options in OpenNMS:

  • Properties files
    • System properties
    • Graph definitions
    • Javamail configuration
  • XML files
  • CFG files
  • Database

And for each of these, there are many different DAO implementations used to read and persist the associated settings.

A major challenge in making the configuration files extensible is that there is hardly any code shared among the configuration DAOs.

The ideal OpenNMS Configuration DAO:

  • Can be used for different file formats (i.e. XML and .properties files)
  • Can be configured to use a specific object when testing (i.e. always return this config)
  • Can force a reload
  • Can reload automatically
  • Can issue a callback when reloaded
  • Can optionally map types, i.e. Model -> Config
  • Supports splitting the configuration into multiple files using:
    • .d style
    • explicit includes
  • Can extend the configuration using services exposed in the OSGi registry
  • Can persist the configuration
    • How to handle split configuration files?
  • Can be used to automatically expose a REST endpoint

This could then be used to refactor all of the existing DAO implementations.

1 Like