Make ompi_info also show PRRTE MCA params

[jsquyres]

Per @rhc54 and @jsquyres phone conversation...

ompi_info behavior

When #7202 is merged, ompi_info will not show PRRTE MCA params. Which is kinda weird, from a user perspective. Ralph and I discussed this on the phone and came up with a tentative strategy on how to fix it:

1. Adjust the PRRTE build order to build after OPAL and before OMPI (i.e., the same ordering in which ORTE used to be built). This will build libprrte.la.
2. If we didn't --no-prrte in autogen.pl (i.e,. have some kind of AM_CONDITIONAL or somesuch), then link libprrte.la against ompi_info.
   • Sidenote: it may be possible/desirable to just dlopen("libprrte.la") instead of compile-time linking against it. I haven't thought this through to know if it's easier or harder (i.e., just dlsym() to find the MCA param list and use it), but it does offer one tantalizing possibility: also being able to show the PMIX MCA params (...and any other future project that uses MCA params).

In this way, all the PRRTE MCA params will be available to ompi_info.

TBD on how to display them -- we'll probably want to display them slightly differently, or qualify them somehow to note that they are PRRTE MCA params, not OMPI MCA params.

Sidenote: As part of #7202, @rhc54 is going to add the following behaviors into prun:

1. Examine argv[0]. If it's:
   • mpirun, then --mca params are OMPI params
   • prun, then --mca params are PRRTE params
2. Add --omca for OMPI MCA, --pxmca for PMIX MCA, --prmca for PRRTE MCA.

This will seem to give nice default behavior for mpirun / prun, but also have explicit methods if a user wants to always be precise, regardless of argv[0].

SIDENOTE: Do we (also?) want --general-mca PROJECT KEY VALUE (i.e., a 3-param form) that can take any MCA param (i.e., from OMPI, PMIX, or PRRTE)?

Another thing to think about: even if we make ompi_info able to show PRRTE and OMPI MCA params, what's the UX for a user to specify them on the mpirun command line -- do they have to know to --prmca these params, and --omca these other params? That might get confusing... Is there a way to make them automatic, if the framework names are unique between the projects?

PRRTE behavior

We might want to also have some ompi_info items (and/or end of configure output?) that shows. For example, #7559 requires PMIx v4 so that tools launching will work. If you add an additional CLI option, we'll build with PMIx v3, but then only direct launch will work.

We should note this behavior somewhere -- end of configure and/or ompi_info, or something.

[rhc54]

Couple of points:

• there is an AM_CONDITIONAL for whether or not prrte is built - see the top-level Makefile.am

• we did make the framework names unique across the various projects, but the automation for parsing the command line could get a little messy to maintain. I'll have to ponder that one - it is an intriguing idea if we can figure out how to make it work without a lot of hardwired coding. I'd rather avoid making the user know what project a key is in as it is already bad enough that they have to know the name of the framework ☹️

[jsquyres]

Ya, agreed on your point of not wanting to hard-wire anything. I was thinking -- in a very hand-wavey-not-thought-through way -- that we don't have to hard-code anything; it would be something like:

for each corpus of MCA params:
    search for this framework+module+param
    if found
        happy=true
        break
if happy:
    ...process the param...

The key being, of course, have an array/list/set/whatever of available MCA param corpuses (corpi?) vs. hard-coding. That was the amorphous reference I made above in terms of dlopen()'ing MCA-loving' libraries (vs. hard-coding building up that list of corpi). Shrug. Haven't thought this through yet -- I think we're basically agreeing.

[rhc54]

I actually think I have a solution for this - the loop was obvious, but how to avoid hardwiring the names of the frameworks was less so. However, with innovative use of a configure argument...one can point prrte at the frameworks.h file of other projects! Will play with it.

[gpaulsen]

I'm working on figuring this out too, so any additional ideas, please post here. I'll make this happen one way or another hopefully this week!

[jjhursey]

You can pick up the PMIx version with prte_info once openpmix/prrte#715 is complete.