Native Code Packaging Changes

From OpenNMS

The ideas here are to give an overivew of the changes necessary to allow the native code portions of opennms to be moved into separate build trees and separate rpm/deb packages from the remaining parts of opennms.

These changes will allow the pure java (i.e. noarch) parts of opennms to be built and distributed independently of the native code parts and allow us to release new versions of opennms without having to re-release the native code which changes very infrequently anyway.

In addition to the separation of the opennms native code into separate packages, the steps below also outline the substitution of native code with noarch substitutes that provide the same base function but may in some instances be less desirable than the native counter parts. This will allow opennms to run effectively on a system where the native code is unavailable or not installed and avoid one of the most common issues that new users of opennms have. (Though this has improved a great deal due to improved logging and appropriate complaining done in the start up code)

Since the substitutions that exist for the native code lack in either performance, compatibility, or functionality the last requirement for this is that opennms can be configured and/or detect the presense of the native code alternative and use that instead of its noarch substitution so as to make using the most capable versions of the code easy.

Lastly it has been discussed that on platforms that support multiple architectures (for example linux-x86_64 also allows one to run i386 binaries) native code for both/all supported platforms should be included. This will enable an administrator to run java or postgresql using either architecture and still have native code appropriate to its architecture.

Contents 1 iplike 1.1 Building iplike 1.2 Packaging iplike 1.2.1 Questions 1.3 Code changes needed in opennms 2 jrrd 2.1 Building libjrrd 2.2 Packaging libjrrd 2.3 Code changes needed in opennms 3 jicmp 3.1 Building libjicmp 3.2 Packaging libjicmp 3.3 Code changes needed in opennms 4 OpenNMS main project 4.1 build

iplike

Building iplike

1. iplike module needs to be moved out of the opennms build into its own module.
2. the iplike build will be converted to use a 'configure' script to make it easier to port to other systems.
3. the new iplike build will need to 'classify' the iplike shared lib needs to be 'classified' with a platform / postgresql tag and published to the opennms repo so it can be used in dependencies for testing(though having a substitute version makes this less important)
4. Need to have differing builds/packages for postgresql version

Packaging iplike

1. This needs to be packaged to depend on postgresql. Having this as a separate package will make moving the opennms database to a different system very simple because we need only install this package on the system where the database is running.
2. C stored procedures are global in postgresql so installing into template1 should make it available to any opennms database we create.
3. On multiarchitecture platform make sure we include libraries built for all supported architectures so we ensure that the code will work on whichever architecture is running (unless it is possible to detect which architectures of postgresql is install so only need to install matching ones?)
4. Need to properly handle detecting postgresql version since the stored procedure code not has version MAGIC in it.

Questions

• Is there a way to make this work with any postgresql database?
• We should probably provide a simple script for adding it to a database.
• Is there a standard place to install postgresql extensions on the various distributions?

Code changes needed in opennms

1. We desire to make the iplike package optional by providing a pl/pgsql version with opennms.
2. We need to check in a pl/pgsql version of the iplike function such as the one provided here: [1] -- Jeffg: I think there are a few tweaks to that function that would speed it up, like special-casing what I imagine are the four most common rules: '*.*.*.*', 'N.*.*.*', 'N.N.*.*', and 'N.N.N.*'. Cut out a little string processing and see how it helps.
3. We need to update the installer to detect if the 'C' version is installed in the database already and use it. If not we need to install a pl/pgsql version and complain in the installer so they are aware but not disabled.

jrrd

Building libjrrd

1. The jrrd code will be modified to provide a very simple interface java file and the associated 'C' code. The build system will be replaced with a 'configure' style build system to make porting it easiest.
2. The jrrd java code and share library will be moved into its own module and built and released separately from the opennms.
3. The jrrd java code and the shared library will have a component that will publish it to the maven repo appropriately classified so it can be used as a maven dependency.

Packaging libjrrd

1. This will be packaged in an architecture specific way depending only on rrdtool.
2. On multi architecture platforms, libraries for all supported architectures will be packaged together (e.g. 32bit and 64bit on an x86_64 system) so there will no confusion since it can be run in either JVM.
3. This will need to be installed in a 'standard' location (maybe as defined here: [2])

Code changes needed in opennms

1. The opennms code only needs to be changed so ensure that the jrrd jar file and the jrrd shared library are properly loaded by opennms.
2. Add detection for currently running JVM achitectures and ensure that it loads the appropriate shared library.
3. Make sure we use jrobin for all testing as possible and that
4. JniRrdStategy uses 'provided' scope for jrrd Interface class. JRobin must continue to be the default implementation.

jicmp

Building libjicmp

1. The jicmp code will be modified to provide a very simple interface java file and the associated 'C' code. The build system will be replaced with a 'configure' style build system to make porting it easiest.
2. The jicmp java code and share library will be moved into its own module and built and released separately from the opennms.
3. The jicmp java code and the shared library will have a component that will publish it to the maven repo appropriately classified so it can be used as a maven dependency.

Packaging libjicmp

1. This will be packaged in an architecture specific with no dependencies
2. Need to ensure that we ship multiple binaries on multiarch platforms such as x86_64.
3. This will need to be installed in a 'standard' location (maybe as defined here: [3]).

Code changes needed in opennms

1. The opennms code only needs to be changed so ensure that the jicmp jar file and the jicmp shared library are properly loaded by opennms.
2. Add detection for currently running JVM achitectures and ensure that it loads the appropriate shared library.
3. Need to make this code optional. Replace uses of ICMP with AVAIL in plugin cases by default. Rework discovery to use the isAvailable API to do find new suspect addresses.

OpenNMS main project

build

1. Extend maven with a plugin (native-mojo) that will detect the current architecture and platform and define a classifier that can be substituted in dependencies
2. Add native dependencies where necessary (in tests and maybe assembly) using appropriate classifier.