Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] RFC - "system-wide-only" MCA parameters
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2009-09-04 03:05:41


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
jsquyres_at_[hidden]