Configuration Persistence

From OpenNMS
Jump to navigation Jump to search

What's this all about

The OpenNMS project has moved to a new DAO persistence strategy for persistence of those objects in the domain model that are stored in the relational database. However, the transactional persistence of configuration objects (the most critical components of the object model, btw) to and from XML has not been addressed.

This use case should define the requirements for persistence of OpenNMS' configuration object model.

Use Case

The users of OpenNMS change the behavioral configuration of an OpenNMS daemon service and the service is not required to be restarted. The change is transactional and compartmentalized so that manual vs. dynamic configuration changes by many users do not negate changes.


  1. An OpenNMS administrator edits the poller configuration file by defining a new service. OpenNMS recognizes the change and all interested components of OpenNMS are aware of the change and apply it immediately if necessary for consistent behavior.
  2. An OpenNMS administrator edits the notifications configuration file while another OpenNMS WebUI user or service changes the configuration. The changes made by the OpenNMS administrator can not be applied. Behavior:
    1. The OpenNMS administrator sends an event to OpenNMS to export the running notification configuration to an XML file.
    2. An OpenNMS user changes the notification configuration via the WebUI.
    3. The OpenNMS Notifd service updates the running configuration with the applied changes and a new transaction ID and serializes the configuration to a binary on the filesystem or in the DB.
    4. The OpenNMS administrator changes the requested exported configuration via XML and sends an event to OpenNMS to update the notification configuration.
    5. The update fails for the transaction ID no longer matches the running configuration's transaction ID.
    6. The OpenNMS repeats the process so that the admin's changes are applied with the current configuration.
    7. When OpenNMS is restarted, the serialized configuration is always loaded unless it doesn't exist.

Initial Thoughts

  1. Transaction IDs in configuration files.