Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2007-07-10 07:39:00


On Jul 10, 2007, at 6:07 AM, Bogdan Costescu wrote:

>> For example, I can readily find machines that are running TM, but
>> also have LSF and SLURM libraries installed (although those
>> environments are not "active" - the libraries in some cases are old
>> and stale, usually present because either someone wanted to look at
>> them or represent an old installation).
>
> Whatever the outcome of this discussion is, please keep in mind that
> this represents an exception rather than the rule. So the common cases
> of no batch environment or one batch environment installed should work
> as effortless as possible. Furthermore, keep in mind that there are
> lots of people who don't compile themselves Open MPI, but rely on
> packages compiled by others (Linux distributions, most likely) - so
> don't make life harder for those who produce these packages.

FWIW, this is exactly the reason that we have the "auto as much as
possible" behavior today; back in LAM/MPI, we had the problem that
[many] users would say "I built LAM, but it doesn't support ABC, even
though your manual says that it does! LAM's a piece of junk!" The
sad fact is that most people assume that "./configure && make
install" will do all the Right magic for their system; efforts at
education seemed to fail. So we took the path of least resistance
and assumed that if we can find it on your system, we should use it.
Specifically: it was more of a support issue than anything else.

>> 1. ... we would only build support for those environments that the
>> builder specifies, and error out of the build process if multiple
>> conflicting environments are specified.
>
> I think that Ralf's suggestion (auto unless forced) is better, as it
> allows:
> - a better chance of finding the environments for people who don't
> have too much experience with building Open MPI or hate to RTFM
> - control over what is built or not for people who know what they
> are doing
>
>> This raises the issue of what to do with rsh, but I think we can
>> handle that one by simply building it wherever possible.
>
> I've been meaning to ask this for some time: is it possible to get rid
> of rsh support when building/running in an environment where rsh is
> not used (like a TM-based one) ? I'm not trying to achieve security by
> doing this (after all, a user can build a separate copy of Open MPI
> with rsh support), but just to make sure that the programs that I
> build are either using the "blessed" start-up mechanism or error out.

Do either of these work for you?

1. Use the --enable-mca-no-build option as I discussed in a mail a
few minutes ago.
2. Remove the "mca_pls_rsh.*" files in $prefix/lib/openmpi.

>> 2. We could laboriously go through all the components and ensure
>> that they
>> check in their selection logic to see if that environment is active.
>
> I might be missing something in the design of batch systems or
> software in general, but how do you decide that an environment is
> active or not ?

Most batch systems today set a sentinel environment variable that we
check for.

> Can a library check if it's being used in a program ?
> Or if that program actually runs ? And if a configuration file exists,
> does it mean that the environment is actually active ?

We do not generally assume that the presence of a plugin means that
that plugin can run in the current environment. I thought that all
framework selection logic was adapted to this philosophy, but
apparently Ralph is indicating that some do not. :-)

> How to deal
> with the case where there are several versions of the same batch
> system installed, all using the same configuration files and therefore
> being ready to run ?

We assume that Open MPI was built compiling/linking against the Right
version. There's not much else we can do if you build against the
Wrong version.

> And how about the case where there is a machine
> reserved for compilations, where libraries are made available but
> there is no batch system active ?

That's what the compile-time vs. run-time detection and selection is
supposed to be for. The presence of an OMPI component at run-time is
not supposed to mean that it can run; it's supposed to be queried and
the component can do whatever checks it wants to see if it is
supposed to run, and then report "Yes, I can run" / "No, I cannot
run" back to Open MPI.

-- 
Jeff Squyres
Cisco Systems