On Sep 3, 2009, at 12:23 PM, Nadia Derbey wrote:
What: Define a way for the system administrator to prevent users from
overwriting the default system-wide MCA parameters settings.
In general, I think this is great stuff. I have a few nit picks.
(BTW: you might want to run contrib/hg/build-hgignore.pl in your svn
+hg tree to generate a proper .hgignore file...?)
I'm currently unable to build the hg tree -- it gets a version with a
newline in it which causes badness in the Makefile. For example:
------
*** Checking versions
checking for SVN version... done
checking Open MPI version... 1.4a1hgf11244ed72b5
up to changeset c4b117c5439b
checking Open MPI release date... Unreleased developer copy
checking Open MPI Subversion repository version... hgf11244ed72b5
up to changeset c4b117c5439b
checking for SVN version... done
...etc.
------
Do you see this, or do you get a single-line version number?
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.
I haven't looked at the code deeply, so forgive me if I'm parsing this
wrong: is the code actually reading the file into one list and then
moving the values to another list? If so, that seems a little
hackish. Can't it just read directly to the target 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".
This seems a little funky, too. Isn't a privileged param actually
read only (in an abstract sense)? Meaning: you can't change priv
param values, so they're "read only". "Priv" feels more like a
"source" attribute, doesn't it...? I.e., it's a read-only param, and
the source of the attribute is the special priv file.
3. A new option has been added to ompi_info(1): --privileged
it outputs only the list of parameters that have been defined as
system-wide-only.
This also feels a bit weird -- I took a quick look through the --priv
handling in ompi_info and it seems there's a bunch of corner cases.
Can you describe what happens and what corner cases occur with --priv?
TODO list:
. Make this feature configurable.
Per my prior post, I think that if we make this configurable, it has
to be a configure script option (not a run-time mca parameter).
. Output a warning message as described in the ticket.
That would be nice.
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
declared set.
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.
Agreed.
--
Jeff Squyres
jsquy...@cisco.com
