Show load errors is defaulting to true

[rhc54]

In v3.x, and on master, the default value for the MCA param "mca_base_component_show_load_errors" is being set to "true". This means that people who install OMPI from a packager get load errors reported for every component whose library isn't installed.

IIRC, our policy was to default this to "false" for just that reason. Did someone change it by mistake?

[jjhursey]

In v2.x and v2.0.x it is default to true as well. I thought this was always the policy to show the load errors by default - did that decision change recently?

[jsquyres]

Yeah, this is a sticky issue -- there are definitely valid arguments for setting the default to both True and False.

Perhaps the least-worst compromise could be:

• Add a configure CLI argument that can set the default of show_load_errors (if it doesn't exist already)
• We advise downstream packagers that they might want to update their builds to set this value to False for the reasons @rhc54 cited.

This would still seem to give safety to the majority of installations out there (i.e., those who build Open MPI themselves with just the libraries that they want, and want to know immediately if a component fails to load because of a missing library, etc.), but give the downstream packagers (who tend to build Open MPI support with everything that they can) a viable option to not have OMPI bombard users with useless warnings.

Thoughts?

[bosilca]

+1 on making the default to False. We can assume that whoever carefully build a minimalistic list of component know what she's doing, so it is not unreasonable to ask her (on the FAQ) to manually set the flag to True.

[jsquyres]

@bosilca Keep in mind that building a minimalistic set of components usually just entails "./configure && make -j 32 && make install". I.e., configure will automatically make a minimalistic set of components based on what it finds on the system.

My $0.02 is that it's more unusual to build Open MPI with a maximal set of components.

However, this is subjective -- I admittedly have no proof either way.

[rhc54]

I'm not sure when the change occurred, but my point was only that it has changed. I know because I have it set to true in my default MCA param file (in my platform files) precisely because, as a developer, I was running into problems with new components that weren't being loaded. So I unfortunately never saw when it changed.

I honestly don't believe the statement that "the majority" of installations are built from scratch - I'm not sure we have any data to support it. I was simply contacted by the OpenHPC folks because they are unexpectedly getting reports of the problem, and it is rather annoying to their users.

Perhaps one solution is to make it true by default on debug builds, and false otherwise? It is, after all, a debug output.

[bosilca]

@jsquyres even for modules depending on particular hardware this is not always the case (libraries and headers are sometimes available). For modules no depending on hardware, they are all compiled despite the fact that most of them will never be used - due to their default priority that almost nobody cares to change. I would love to see some statistics about this ... but is outside the scope of the current discussion.

[jsquyres]

Let's discuss on Tuesday.

[jjhursey]

git blame on https://github.com/open-mpi/ompi/blame/master/opal/mca/base/mca_base_open.c#L105 shows that it has not changed from true in the past 5 years. Looks like it was false before that. Here is the commit

• cf377db

We are in the 'build the maximal set of components' camp - which is possibly rare. We have to explicitly set this value to false by default in our conf file because it was annoying to see all of the load issues depending on where we were running. Users can override, of course.

I think discussing this default is a good idea. Setting it to false by default might be a good idea.

[rhc54]

The telecon today left this with the feeling that we should at least create a new configure option for setting the default value. There was some discussion as to the proper default for that option - one suggestion (that at least two of us favored) was to set it true for debug builds, but false for non-debug builds. No definitive decision was made.