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 think that's the best that we can do.
--
Jeff Squyres
jsquy...@cisco.com
