What happens if $sysconfdir/openmpi-priv-mca-params.conf is missing ?
Can the file name ( openmpi-priv-mca-params.conf ) also be configurable ?
On 9/3/09 5:23 AM, "Nadia Derbey" <Nadia.Derbey_at_[hidden]> wrote:
What: Define a way for the system administrator to prevent users from
overwriting the default system-wide MCA parameters settings.
Why: Letting the user completely free of changing any MCA parameter
that has been defined on a system-wide basis may sometimes be
Where: code can be found at
Letting the user completely free of changing any parameter that has been
defined on a system-wide basis may sometimes be undesirable. For
example, on a node with multiple TCP interfaces, the system
administrator may for some reason want to restrict MPI applications to a
fixed subset of these TCP interfaces.
Today, there is no way for the system administrator to prevent users
from overwriting the default system-wide settings: even if he has
excluded eth0 from the interfaces usable by an MPI application, he
cannot prevent any user from explicitly using that excluded interface.
The purpose of this feature is to provide a new "system-wide-only"
property for the MCA parameters, specifying that their system-wide
value, if it has been defined, can never be overridden. This implies
changing the existing parameters setting rules.
It should be noted that this feature is already described in
https://svn.open-mpi.org/trac/ompi/ticket/75 as follows:
"another MCA parameter file that has "privileged" MCA parameters. This
file is hard-coded in the code base (based on $prefix, likely
"$sysconfdir/openmpi-priv-mca-params.conf", or somesuch). Any parameters
set in this file will be treated specially and cannot be overridden."
But we chose another way to implement this feature: the file
$sysconfdir/openmpi-mca-params.conf is kept with all the parameters
settings (even those that are considered as system-wide-only).
And the new file $sysconfdir/openmpi-priv-mca-params.conf is introduced
to contain only the list of the "privileged" parameters (not their value).
Doing it that way makes it easier to change the status of the MCA
parameters: moving them from privileged to non privileged is only a
matter of removing the new file, which preserves compatibility.
While with the solution proposed in the ticket, we have to merge both files.
The configuration files are parsed in the following order:
When openmpi-priv-mca-params.conf is parsed, any parameter listed in
that file is moved from the mca_base_param_file_values list to a new
parallel list (mca_base_priv_param_file_values). The parameter remains
"hidden" in that new list.
The lookup order has been changed: the new
mca_base_priv_param_file_values list is the very 1st one to be scanned:
this is how we ensure that the "privileged" parameters are never
overwritten once defined on a system-wide basis.
Other external changes:
1. The man page for mpirun(1) has been changed.
2. The ompi_info(1) output has been changed to reflect the status of
these "privileged" parameters. The status field can now be one of
"read-only", "writable" or "privileged".
3. A new option has been added to ompi_info(1): --privileged
it outputs only the list of parameters that have been defined as
. Make this feature configurable.
. Output a warning message as described in the ticket.
Possible extension to this functionality:
This new functionality can be extended in the future in the following
way: allow the administrator to specify boundaries within which an MCA
parameter is allowed to be changed by a higher priority setting. This
means that the administrator should declare min and max values (or even
a set of discrete values) for any such parameter. Then, any higher
priority setting will be done only if the new value belongs to the
In other word, each MCA parameter can be
1. set to a given value in openmpi-mca-params.conf
2. declared in openmpi-priv-mca-params.conf with its allowed boundaries
Then, if the user calls mpirun with that MCA parameter set in his
private mca-params.conf file, or in an AMCA file, or in an environment
variable, or on the command line, the new value will override the
system-wide value only if it is within the declared boundaries.
This could be thought of as a future development.
Nadia Derbey <Nadia.Derbey_at_[hidden]>
devel mailing list