Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI devel] RFC - "system-wide-only" MCA parameters
From: Ralph Castain (rhc_at_[hidden])
Date: 2009-09-05 11:10:43

On Sep 5, 2009, at 3:00 AM, Jeff Squyres wrote:

> On Sep 4, 2009, at 5:47 PM, Sylvain Jeaugey wrote:
>> Understood. So, let's say that we're only implementing a hurdle to
>> discourage users from doing things wrong. I guess the efficiency of
>> this
>> will reside in the message displayed to the user ("You are about to
>> break
>> the entire machine and you will be fined if you try to circumvent
>> this in
>> any way").
>> Maybe the warning message should be set by administrators
>> ($OMPI/.../no-override.txt). It would certainly be more efficient :)
> Ralph is certainly right: there is no way that we can prevent users
> -- even those with the best of intentions -- from circumventing the
> system when they perceive the system not working they way they want
> it to (such is the nature of open source). So this functionality is
> just adding another hurdle towards trying to help prevent that
> behavior. It does help in [ISV] applications where OMPI is
> statically linked to the app -- in that case, the user *won't* be
> able to just replace the system OMPI with their own.
> That being said, it does seem like the best-functioning hurdle would
> be to print a site-specific message when users try to override priv
> params ("Bob the sysadmin set a parameter for this system that you
> tried to override. See http://internal/why-ompi-is-set-this-way.hml
> for an explanation of OMPI site-wide settings"). This might give
> well-intentioned users a clue as to *why* the system is not
> functioning the way that they expect, potentially educating them and
> deterring circumventing the system.

I really like this addition - if users just see something not work,
they will tend to believe something is broken and try to develop
workarounds. Explaining -why- it is restricted will help reduce that

> I think that's the best that we can do.
> --
> Jeff Squyres
> jsquyres_at_[hidden]
> _______________________________________________
> devel mailing list
> devel_at_[hidden]