MCA parameters that cannot be understood should cause warnings/errors

[abouteiller]

Description

Some time ago we changed --mca runtime_bind_thread to --mca bind_thread. Passing in the obsolete value is silently ignored, which is really error prone for end users.

Learning from that story, we should not silently ignore incorrect arguments.

Describe the solution you'd like

We should warn when invalid mca parameters are passed-in.

Describe alternatives you've considered

We could also error out when invalid mca parameters are passed-in, but that may cause errors to be generated when the mca param file contains options that are relevant for another in-work branch.

[devreal]

This wouldn't catch env variables though right? That's the mechanism I'm using (PARSEC_MCA_....)

[abouteiller]

For v4 I will reduce the scope of this to only warning about parameters that we used to have but have been removed. Capturing arbitrary wrong params would be good but looks difficult to achieve atm.

[bosilca]

It is not possible to identify neither unused nor incorrect MCA params. The first because we extract all registered MCA params in local variables, and after this parsec does not know if the value is used or not. The second, because we transform command line MCA params into environment variables, and the environment is only searched for registered MCA param.

At best, we could write a search that goes over all the environment variables that start with PARSEC_MCA and try to match them with a registered param. Failing to find one will identify the MCA as non-existent. For the other types of params (such as files) we could mark them as registered, and then upon finalization (we can't do this during init because components can be lazily loaded) print all those that do not have a registered MCA.

We can identify the unused MCA parameters from the configuration file, by checking if parsec_mca_param_file_values is empty upon finalize.