Try to avoid upgrade conflicts with config file changes

Description

Hello,

OpenNMS does not have a good strategy to avoid conflicts on each upgrade with modified config files. If I changed any xml/property file, it creates a .rpmnew file and asks me to solve it. OpenNMS should try to avoid this rework.

In Linux, the most used solution for this is to use isolated files inside a directory (like /etc/profile.d/ or any /etc/*.d/). For OpenNMS, I don't know how this would like.

Some options:
1) Add optional directory. Files with the same structure of the main config file is merged into the main config on load. Conflicts are reported to admin.
2) Split the main config files into small parts. Files are loaded and joined on load, with conflicts reported to admin.

Any other ideas?

Environment

Operating System: Linux Platform: PC

Acceptance / Success Criteria

None

Attachments

3
  • 06 Aug 2010, 10:47 AM
  • 05 Aug 2010, 01:23 PM
  • 25 Jun 2010, 07:01 PM

depends on

Lucidchart Diagrams

Activity

Bruce Smith September 8, 2010 at 3:11 AM

The biggest areas I ran into manual merging issues where the custom data/snmp pollers and custom snmp-graphs. The ability to include a file into a unmodified opennms config file would solve these problems for me as I can keep my changes separate.

Luiz Angelo Daros de Luca August 6, 2010 at 10:47 AM

Created an attachment (id=1063)
Restore first script as it should not use etc-pristine

Ops, I did a mistake (tm). I cannot use etc-pristine. I must keep looking for .old files. I restored the first script

Tarus Balog August 6, 2010 at 7:09 AM

We have a number of "best practices" to avoid issues with upgrades, such as putting all new configs in their own separate packages, etc.

However, this script looks pretty cool.

Les Mikesell August 5, 2010 at 2:17 PM

RedHat-style systems often use both approaches (1) and (2) above. That is, where possible they extract the things generally set as local config changes or options into their own files (normally under /etc/sysconfig but the location doesn't matter) and they split optional/modular configuration components into *.d/ directories where each rpm can add its own snippet as needed without worrying much about what else is there. For opennms, I'd think approach (1) is the more important piece - separate the local/user config from the rpm-supplied defaults and let them override the defaults. That way updates can (nearly) always overwrite the unchanged default files while keeping local changes/additions. Approach (2) would be good for canned optional configuration settings, though.

Luiz Angelo Daros de Luca August 5, 2010 at 1:23 PM

Created an attachment (id=1061)
Script to fix config files after upgrade

Details

Assignee

Reporter

Labels

Components

Affects versions

Priority

PagerDuty

Created December 15, 2009 at 10:45 AM
Updated September 21, 2021 at 6:22 PM

Flag notifications