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
reaction.
I think that's the best that we can do.
--
Jeff Squyres
jsquy...@cisco.com
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
