Proposal 3

This proposal was discussed in and around LDMSCON 2019 as the result of tutorial development, rather than as an issue on the tracker. We seek to empower the community to develop plugins in a way which makes it relatively painless to integrate them into builds of the ovis framework and package them widely. Additional discussion is at: https://github.com/ovis-hpc/ovis/pull/72.

Out of scope here is discussion of better C APIs. Only build decoupling and integration figures here.

Requirements and constraints

• Provide a way for 3rd parties to create and correctly build their own plugins.
  • Ensure all needed build and installation information (libs, headers, compiler information) is trivially available from a packaged installation.
  • 3rd Party definition to include alpha/beta plugins not fully tested or officially supported by the OVIS development team.
• Provide examples of 3rd party plugins (including build) which, if emulated, result in it being a matter of dropping their code into an ldms repository contrib subtree.
• Enable robust building of 3rd party plugins in the contrib subtree without tying their autogen process to ours (no automake variable references to 3rd party plugin directories, but post-install script hooks to launch 3rd party build are ok).
• No ovis ".c" files are needed for building plugins. Only headers and libraries.
• No ovis libtool (.la) files are needed for building plugins.

Possible solutions

1. Provide LDMS dependent project build examples, but keep 3rd party code entirely out ldms tree (no 'contrib' directories). Third party/alpha plugins could be incorporated in binary packaging, but they would be on the packaging organization to support.
2. Add post-install hooks to the build, such that after make install in lib or ldms, the hook tries to build any packages that were listed in a configure argument.
3. Have a ldms/src/contrib tree, where each contribution is by default disabled in the ovis configure.

Evaluation of solutions

• (1) places the least burden on core maintainers but is less encouraging of community involvement. It also tends to lead to violations (bit rot) of the requirement to ensure that all needed information is exported to 3rd parties by the base installation.
• (3) has bee prototyped in https://github.com/ovis-hpc/ovis/pull/88 for version 4.3.
• (2) has been prototyped as https://github.com/ovis-hpc/ovis/pull/72 for version 4.3. The prototype has the following properties:
  • Each plugin or plugin set lives in its own directory. Subtrees are possible.
  • There is no back-compatibility with previously released versions of ovis (which do not ensure all needed build information is available).
  • The third-plugins projects copied into the ovis source tree are managed by the base build (post-install) launching a specifically named shell script, ldms_build.sh.
    • This ldms_build.sh script is responsible for compiling and installing to the ovis install locations all in one shot; the ovis location configurations are all provided by the base install in $ovis_ldms_pkglibdir files.
    • The ovis source tree provides example of ldms_build.sh based on autotools.
    • Users desiring to use some other build system (bjam, cmake, gnu make) are not constrained to use autotools.
  • The third-plugins example provided as part of ldms includes a my_build.sh script that allows the plugin to be built, debugged, and installed without being part of an ovis source tree build.
  • Unless an environment override is provided, the ldmsd installation found in the user's PATH is used by my_plugin.sh to build the plugins and installation will be to the ldms installation tree locations.
  • The plugin developer is free to modify the install arguments or process used in their variant of my_plugin.sh as desired.

Resolution thus far:

• Solution 2 (#PR 88)is generally agreeable to those that discussed it as part of the PR #72 discussion. UPDATE: #PR96 which was rebased #PR88 has been merged into master.
• Solution 3 (# PR 72) has mixed reviews.