Deprecated MCA variable warning mistakenly quotes config file as source of issue instead of environment
Background information
What version of Open MPI are you using? (e.g., v4.1.6, v5.0.1, git branch name and hash, etc.)
v5.0.2
Describe how Open MPI was installed (e.g., from a source/distribution tarball, from a git clone, from an operating system distribution package, etc.)
From EFA Installer
Please describe the system on which you are running
- Operating system/version:
- Computer hardware:
- Network type:
Details of the problem
If there is a mca params file such as $prefix/etc/openmpi-mca-params.conf then when user sets deprecated mca parameters on the command line, the help message mistakenly blames the params file, even though the environment should be blamed:
ubuntu@ip-172-31-47-127:/fsx/lrbison$ OMPI_MCA_mca_component_show_load_errors=0 mpirun -n 1 hostname
--------------------------------------------------------------------------
A deprecated MCA variable value was specified in an MCA variable
file. Deprecated MCA variables should be avoided; they may disappear
in future releases.
Deprecated variable: mca_component_show_load_errors
Source file: /opt/amazon/openmpi5/etc/openmpi-mca-params.conf
New variable: mca_base_component_show_load_errors
--------------------------------------------------------------------------
ip-172-31-47-127
ubuntu@ip-172-31-47-127:/fsx/lrbison$ mpirun -n 1 hostname
ip-172-31-47-127
ubuntu@ip-172-31-47-127:/fsx/lrbison$
I'm gonna reproduce with source build instead of EFA installer.
It hit this line
I think perhaps the easy solution is sufficient:
A deprecated MCA variable value was specified in an MCA variable
file or in the user's environment or run-time options. Deprecated
MCA variables should be avoided; they may disappear in future
releases.
?
It can simplify things but I guess the separation is intended. There are different hints for param file, cli and env paramters. https://github.com/open-mpi/ompi/blob/1f87690b7d8b9ffce43c6f5dfd8f30efc156a914/opal/mca/base/help-mca-var.txt#L39-L58
So far this looks like a valid bug in the parser somewhere.