subject:"\[OMPI users\] Question about scheduler support"


Em 15-05-2014 20:48, Ralph Castain escreveu:

Nobody is disagreeing that one could find a way to make CMake work - all we are 
saying is that (a) CMake has issues too, just like autotools, and (b) we have 
yet to see a compelling reason to undertake the transition...which would have 
to be a *very* compelling one.


I was simply agreeing with Maxime about why it could work. ;)

But if you and the other devels are fine with it, i'm fine too.

Re: [OMPI users] Question about scheduler support

Nobody is disagreeing that one could find a way to make CMake work - all we are 
saying is that (a) CMake has issues too, just like autotools, and (b) we have 
yet to see a compelling reason to undertake the transition...which would have 
to be a *very* compelling one.


On May 15, 2014, at 4:45 PM, Fabricio Cannini  wrote:

> Em 15-05-2014 20:15, Maxime Boissonneault escreveu:
>> Le 2014-05-15 18:27, Jeff Squyres (jsquyres) a écrit :
>>> On May 15, 2014, at 6:14 PM, Fabricio Cannini  wrote:
>>> 
 Alright, but now I'm curious as to why you decided against it.
 Could please elaborate on it a bit ?
>>> OMPI has a long, deep history with the GNU Autotools.  It's a very
>>> long, complicated story, but the high points are:
>>> 
>>> 1. The GNU Autotools community has given us very good support over the
>>> years.
>>> 2. The GNU Autotools support all compilers that we want to support,
>>> including shared library support (others did not, back in 2004 when we
>>> started OMPI).
>>> 3. The GNU Autotools can fully bootstrap a tarball such that the end
>>> user does not need to have the GNU Autotools installed to build an
>>> OMPI tarball.
> 
> I have doubt about #3 too, but :
> #1 should not be a problem for the amount of projects already using cmake;
> #2 too, as gromacs [ http://gromacs.org/ ] has been using cmake since the 4.6 
> series, and it has tons of options for compilers, math libraries, cuda, 
> opencl ...
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users

Re: [OMPI users] Question about scheduler support


Em 15-05-2014 20:15, Maxime Boissonneault escreveu:

Le 2014-05-15 18:27, Jeff Squyres (jsquyres) a écrit :

On May 15, 2014, at 6:14 PM, Fabricio Cannini  wrote:


Alright, but now I'm curious as to why you decided against it.
Could please elaborate on it a bit ?

OMPI has a long, deep history with the GNU Autotools.  It's a very
long, complicated story, but the high points are:

1. The GNU Autotools community has given us very good support over the
years.
2. The GNU Autotools support all compilers that we want to support,
including shared library support (others did not, back in 2004 when we
started OMPI).
3. The GNU Autotools can fully bootstrap a tarball such that the end
user does not need to have the GNU Autotools installed to build an
OMPI tarball.


I have doubt about #3 too, but :
#1 should not be a problem for the amount of projects already using cmake;
#2 too, as gromacs [ http://gromacs.org/ ] has been using cmake since 
the 4.6 series, and it has tons of options for compilers, math 
libraries, cuda, opencl ...

Re: [OMPI users] Question about scheduler support


On May 15, 2014, at 4:15 PM, Maxime Boissonneault 
 wrote:

> Le 2014-05-15 18:27, Jeff Squyres (jsquyres) a écrit :
>> On May 15, 2014, at 6:14 PM, Fabricio Cannini  wrote:
>> 
>>> Alright, but now I'm curious as to why you decided against it.
>>> Could please elaborate on it a bit ?
>> OMPI has a long, deep history with the GNU Autotools.  It's a very long, 
>> complicated story, but the high points are:
>> 
>> 1. The GNU Autotools community has given us very good support over the years.
>> 2. The GNU Autotools support all compilers that we want to support, 
>> including shared library support (others did not, back in 2004 when we 
>> started OMPI).
>> 3. The GNU Autotools can fully bootstrap a tarball such that the end user 
>> does not need to have the GNU Autotools installed to build an OMPI tarball.
> You mean some people do NOT have GNU Autotools ? :P

Actually, yes - Cray doesn't install them.

> 
> Jokes aside, CMake has certainly matured enough for point #2 and is used by 
> very big projects (KDE for example). Not sure about point #3 though. I am 
> wondering though, how do you handle Windows with OpenMPI and GNU Autotools ? 
> I know CMake is famous for being cross-plateform (that's what the C means) 
> and can generate builds for Windows, Visual Studio and such.
> 

The Windows integration actually involved adding CMake support within OMPI. It 
was truly an ugly effort that caused the student who took it on a great deal of 
pain. Ultimately, that support was scrapped when the student graduated and 
nobody was willing to maintain it.

> In any case, I do not see any need to change from one toolchain to another, 
> although I have seen many projects providing both and that did not seem to be 
> too much of a hassle. It's still probably more work than what you want to get 
> into though.

Yeah, as Jeff indicated, without a burning justification, it just doesn't seem 
worth it.

> 
> Maxime
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users

Re: [OMPI users] Question about scheduler support


Le 2014-05-15 18:27, Jeff Squyres (jsquyres) a écrit :

On May 15, 2014, at 6:14 PM, Fabricio Cannini  wrote:


Alright, but now I'm curious as to why you decided against it.
Could please elaborate on it a bit ?

OMPI has a long, deep history with the GNU Autotools.  It's a very long, 
complicated story, but the high points are:

1. The GNU Autotools community has given us very good support over the years.
2. The GNU Autotools support all compilers that we want to support, including 
shared library support (others did not, back in 2004 when we started OMPI).
3. The GNU Autotools can fully bootstrap a tarball such that the end user does 
not need to have the GNU Autotools installed to build an OMPI tarball.

You mean some people do NOT have GNU Autotools ? :P

Jokes aside, CMake has certainly matured enough for point #2 and is used 
by very big projects (KDE for example). Not sure about point #3 though. 
I am wondering though, how do you handle Windows with OpenMPI and GNU 
Autotools ? I know CMake is famous for being cross-plateform (that's 
what the C means) and can generate builds for Windows, Visual Studio and 
such.


In any case, I do not see any need to change from one toolchain to 
another, although I have seen many projects providing both and that did 
not seem to be too much of a hassle. It's still probably more work than 
what you want to get into though.


Maxime

Re: [OMPI users] Question about scheduler support

2014-05-15 Thread Jeff Squyres (jsquyres)

On May 15, 2014, at 6:14 PM, Fabricio Cannini  wrote:

> Alright, but now I'm curious as to why you decided against it.
> Could please elaborate on it a bit ?

OMPI has a long, deep history with the GNU Autotools.  It's a very long, 
complicated story, but the high points are:

1. The GNU Autotools community has given us very good support over the years.
2. The GNU Autotools support all compilers that we want to support, including 
shared library support (others did not, back in 2004 when we started OMPI).
3. The GNU Autotools can fully bootstrap a tarball such that the end user does 
not need to have the GNU Autotools installed to build an OMPI tarball.

#2 and #3 were the most important reasons back in the beginning of the project.

Periodically, we have looked at other tools over the years because the GNU 
Autootols are far from perfect, too (scons, cmake, etc.).  The other tools 
either still failed #2 or #3, or were not enough of an improvement to justify 
the time/effort to re-write OMPI's configure/build system.  

To be clear: we'd need a *very* strong reason to move to another toolchain at 
this point.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI users] Question about scheduler support


Em 15-05-2014 18:40, Ralph Castain escreveu:


On May 15, 2014, at 2:34 PM, Fabricio Cannini  wrote:


Em 15-05-2014 07:29, Jeff Squyres (jsquyres) escreveu:

I think Ralph's email summed it up pretty well -- we unfortunately have (at 
least) two distinct groups of people who install OMPI:

a) those who know exactly what they want and don't want anything else
b) those who don't know exactly what they want and prefer to have everything 
installed, and have OMPI auto-select at run time exactly what to use based on 
the system on which it's running

We've traditionally catered to the b) crowd, and made some not-very-easy-to-use 
capabilities for the a) crowd (i.e., you can manually disable each plugin you 
don't want to build via configure, but the syntax is fairly laborious).

Ralph and I talked about the possibility of something analogous to "make 
menuconfig" for Linux kernels, where you get a menu-like system (UI TBD) to pick 
exactly what options you want/don't want.  That will output a text config file that can 
be fed to configure, something along the lines of

   ./configure --only-build-exactly-this-stuff=file-output-from-menuconfig

This idea is *very* rough; I anticipate that it will change quite a bit over 
time, and it'll take us a bit of time to design and implement it.



Please allow me to chip in my $0.02 and suggest to not reinvent the wheel, but 
instead consider to migrate the build system to cmake :


LOL - that would require a massive rewrite that I don't think any of us are 
wiling to undertake! Besides, we looked at cmake before, and the negatives 
outweighed the benefits from our perspective at that time - not sure we'd 
change that opinion today.


Alright, but now I'm curious as to why you decided against it.
Could please elaborate on it a bit ?

Re: [OMPI users] Question about scheduler support


On May 15, 2014, at 2:34 PM, Fabricio Cannini  wrote:

> Em 15-05-2014 07:29, Jeff Squyres (jsquyres) escreveu:
>> I think Ralph's email summed it up pretty well -- we unfortunately have (at 
>> least) two distinct groups of people who install OMPI:
>> 
>> a) those who know exactly what they want and don't want anything else
>> b) those who don't know exactly what they want and prefer to have everything 
>> installed, and have OMPI auto-select at run time exactly what to use based 
>> on the system on which it's running
>> 
>> We've traditionally catered to the b) crowd, and made some 
>> not-very-easy-to-use capabilities for the a) crowd (i.e., you can manually 
>> disable each plugin you don't want to build via configure, but the syntax is 
>> fairly laborious).
>> 
>> Ralph and I talked about the possibility of something analogous to "make 
>> menuconfig" for Linux kernels, where you get a menu-like system (UI TBD) to 
>> pick exactly what options you want/don't want.  That will output a text 
>> config file that can be fed to configure, something along the lines of
>> 
>>   ./configure --only-build-exactly-this-stuff=file-output-from-menuconfig
>> 
>> This idea is *very* rough; I anticipate that it will change quite a bit over 
>> time, and it'll take us a bit of time to design and implement it.
> 
> 
> Please allow me to chip in my $0.02 and suggest to not reinvent the wheel, 
> but instead consider to migrate the build system to cmake :

LOL - that would require a massive rewrite that I don't think any of us are 
wiling to undertake! Besides, we looked at cmake before, and the negatives 
outweighed the benefits from our perspective at that time - not sure we'd 
change that opinion today.

> 
> http://www.cmake.org/
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users

Re: [OMPI users] Question about scheduler support

2014-05-15 Thread Nathan Hjelm

On Thu, May 15, 2014 at 06:34:20PM -0300, Fabricio Cannini wrote:
> Em 15-05-2014 07:29, Jeff Squyres (jsquyres) escreveu:
> >I think Ralph's email summed it up pretty well -- we unfortunately have (at 
> >least) two distinct groups of people who install OMPI:
> >
> >a) those who know exactly what they want and don't want anything else
> >b) those who don't know exactly what they want and prefer to have everything 
> >installed, and have OMPI auto-select at run time exactly what to use based 
> >on the system on which it's running
> >
> >We've traditionally catered to the b) crowd, and made some 
> >not-very-easy-to-use capabilities for the a) crowd (i.e., you can manually 
> >disable each plugin you don't want to build via configure, but the syntax is 
> >fairly laborious).
> >
> >Ralph and I talked about the possibility of something analogous to "make 
> >menuconfig" for Linux kernels, where you get a menu-like system (UI TBD) to 
> >pick exactly what options you want/don't want.  That will output a text 
> >config file that can be fed to configure, something along the lines of
> >
> >   ./configure --only-build-exactly-this-stuff=file-output-from-menuconfig
> >
> >This idea is *very* rough; I anticipate that it will change quite a bit over 
> >time, and it'll take us a bit of time to design and implement it.
> 
> 
> Please allow me to chip in my $0.02 and suggest to not reinvent the wheel,
> but instead consider to migrate the build system to cmake :

Umm, no.

IMHO, CMake has its own set of issues. So, its likely not going to happen.

-Nathan Hjelm
HPC-5, LANL


pgpV2U7xXfd2R.pgp
Description: PGP signature

Re: [OMPI users] Question about scheduler support





Please allow me to chip in my $0.02 and suggest to not reinvent the 
wheel, but instead consider to migrate the build system to cmake :


http://www.cmake.org/
I agree that menu-wise, CMake does a pretty good job with ccmake, and is 
much, much easier to create than autoconf/automake/m4 stuff (I speak 
from experience).


However, for the command-line arguments, I find cmake non-intuitive and 
pretty cumbersome. As example, to say

--with-tm=/usr/local/torque

with CMAKE, you would have to do something like
-DWITH_TM:STRING=/usr/local/torque


Maxime

Re: [OMPI users] Question about scheduler support


Em 15-05-2014 07:29, Jeff Squyres (jsquyres) escreveu:

I think Ralph's email summed it up pretty well -- we unfortunately have (at 
least) two distinct groups of people who install OMPI:

a) those who know exactly what they want and don't want anything else
b) those who don't know exactly what they want and prefer to have everything 
installed, and have OMPI auto-select at run time exactly what to use based on 
the system on which it's running

We've traditionally catered to the b) crowd, and made some not-very-easy-to-use 
capabilities for the a) crowd (i.e., you can manually disable each plugin you 
don't want to build via configure, but the syntax is fairly laborious).

Ralph and I talked about the possibility of something analogous to "make 
menuconfig" for Linux kernels, where you get a menu-like system (UI TBD) to pick 
exactly what options you want/don't want.  That will output a text config file that can 
be fed to configure, something along the lines of

   ./configure --only-build-exactly-this-stuff=file-output-from-menuconfig

This idea is *very* rough; I anticipate that it will change quite a bit over 
time, and it'll take us a bit of time to design and implement it.



Please allow me to chip in my $0.02 and suggest to not reinvent the 
wheel, but instead consider to migrate the build system to cmake :


http://www.cmake.org/

Re: [OMPI users] Question about scheduler support

Hi Gus

The issue is that you have to work thru all the various components (leafing 
thru the code base) to construct a list of all the things you *don't* want to 
build. By default, we build *everything*, so there is no current method to 
simply "build only what I want".

For those building static, for example, this results in a much larger binary 
than really necessary. Those wanting a minimal build to avoid confusion (e.g., 
"why do i show slurm when I'm running moab?") face a similar issue.

What we agree on is the need to provide the "build only what I want" 
capability. What Maxime has proposed is one way of doing that for at least the 
schedulers. Jeff and I are discussing additional options.


On May 15, 2014, at 10:59 AM, Gus Correa  wrote:

> Hi List
> 
> Sorry, but I confess I am having a hard time to understand
> all the fuss about this.
> 
> At least in OMPI 1.6.5 there are already
> two configure options that just knock out support for slurm and
> loadleveler if they are set to "no", hopefully for the joy of everybody
> that want lean and mean OMPI installations.
> (Maybe those options are available in OMPI 1.8.1 also?
> I haven't tried it.)
> 
> Just configure:
> 
> --with-slurm=no --with-loadleveler=no
> 
> One could go on and on and make a comprehensive list of all options
> that one wants in/out, and configure with/without all of them.
> 
> **
> 
> Isn't this level of simplicity, effectiveness, and of
> standard use of configure options, good enough for us?
> 
> Works for me.
> 
> **
> 
> IMHO, what would help is to very clearly document
> on the "configure --help" output what is the default value of
> *all* options.
> 
> This would allow system administrators and other users to safely
> make informed choices (or just let the defaults go, if they prefer).
> Although I must say right now "configure --help" is not that bad at all. I am 
> not frustrated with it. It may need only a few tweaks.
> 
> Currently the --with-slurm and --with-loadleveler options
> are clearly documented as having "yes" as the default.
> However, other options don't have so clearly documented defaults.
> In particular -with-tm Torque (which seems to depend on its libraries and 
> headers being found or not by configure).
> By contrast --with-sge clearly says "no" is the default.
> 
> This covers pretty much all free/open source schedulers,
> correct me if I am wrong, please.
> 
> LSF seems not to have a clearly documented default also.
> But LSF is for the rich. I am out.
> 
> My 2 cents, 2nd edition, out of print.
> Bye, thanks, regards.
> Gus Correa
> 
> 
> On 05/15/2014 09:35 AM, Jeff Squyres (jsquyres) wrote:
>> These are all good points -- thanks for the feedback.
>> 
>> Just to be clear: my point about the menu system was to generate file that 
>> could be used for subsequent installs, very specifically targeted at those 
>> who want/need scriptable installations.
>> 
>> One possible scenario could be: you download OMPI, run the menu installer so 
>> that you can see the options that are available, pick the ones you want, 
>> generate the file, and then use it in automated installs (e.g., ./configure 
>> --only-build-this-stuff=file_I_created_from_menu_installer).
>> 
>> I am presuming that the generated file will be text, so it could be 
>> built/edited by hand, too.  This is heavily inspired by the Linux kernel's 
>> "make menuconfig": it generates a .config file that you can use for 
>> subsequent builds.
>> 
>> We can also look at the possibility of providing a template file that lists 
>> all options that are available in that particular tarball (similar to the 
>> Linux kernel "make config").
>> 
>> This, BTW, is one part where we need to build some new infrastructure: to 
>> register and discover all available options (history has shown that just 
>> maintaining a text file for a project the size of Open MPI is not feasible 
>> -- it'll get stale/out of date).
>> 
>> Other large projects do this kind of thing; we need to see if there's any 
>> ideas/code we can borrow rather than completely re-inventing the wheel.
>> 
>> Again, these are just my thoughts after having thought about this for only 
>> about 30 minutes -- so this is likely quite rough and may not even resemble 
>> what we finally end up with.
>> 
>> 
>> On May 15, 2014, at 8:51 AM, Noam Bernstein  
>> wrote:
>> 
>>> I’m not sure how this would apply to other options, but for the scheduler, 
>>> what about no scheduler-related options defaults to everything enabled 
>>> (like before), but having any explicit scheduler enable option disables by 
>>> default all the other schedulers? Multiple explicit enable options would 
>>> enable all the requested schedulers, and disable everything else.
>>> 
>>> 
>>> Noam
>>> ___
>>> users mailing list
>>> us...@open-mpi.org
>>> http://www.open-mpi.org/mai

Re: [OMPI users] Question about scheduler support

2014-05-15 Thread Gus Correa


Hi List

Sorry, but I confess I am having a hard time to understand
all the fuss about this.

At least in OMPI 1.6.5 there are already
two configure options that just knock out support for slurm and
loadleveler if they are set to "no", hopefully for the joy of everybody
that want lean and mean OMPI installations.
(Maybe those options are available in OMPI 1.8.1 also?
I haven't tried it.)

Just configure:

--with-slurm=no --with-loadleveler=no

One could go on and on and make a comprehensive list of all options
that one wants in/out, and configure with/without all of them.

**

Isn't this level of simplicity, effectiveness, and of
standard use of configure options, good enough for us?

Works for me.

**

IMHO, what would help is to very clearly document
on the "configure --help" output what is the default value of
*all* options.

This would allow system administrators and other users to safely
make informed choices (or just let the defaults go, if they prefer).
Although I must say right now "configure --help" is not that bad at all. 
I am not frustrated with it. It may need only a few tweaks.


Currently the --with-slurm and --with-loadleveler options
are clearly documented as having "yes" as the default.
However, other options don't have so clearly documented defaults.
In particular -with-tm Torque (which seems to depend on its libraries 
and headers being found or not by configure).

By contrast --with-sge clearly says "no" is the default.

This covers pretty much all free/open source schedulers,
correct me if I am wrong, please.

LSF seems not to have a clearly documented default also.
But LSF is for the rich. I am out.

My 2 cents, 2nd edition, out of print.
Bye, thanks, regards.
Gus Correa


On 05/15/2014 09:35 AM, Jeff Squyres (jsquyres) wrote:

These are all good points -- thanks for the feedback.

Just to be clear: my point about the menu system was to generate file that 
could be used for subsequent installs, very specifically targeted at those who 
want/need scriptable installations.

One possible scenario could be: you download OMPI, run the menu installer so 
that you can see the options that are available, pick the ones you want, 
generate the file, and then use it in automated installs (e.g., ./configure 
--only-build-this-stuff=file_I_created_from_menu_installer).

I am presuming that the generated file will be text, so it could be built/edited by hand, 
too.  This is heavily inspired by the Linux kernel's "make menuconfig": it 
generates a .config file that you can use for subsequent builds.

We can also look at the possibility of providing a template file that lists all options 
that are available in that particular tarball (similar to the Linux kernel "make 
config").

This, BTW, is one part where we need to build some new infrastructure: to 
register and discover all available options (history has shown that just 
maintaining a text file for a project the size of Open MPI is not feasible -- 
it'll get stale/out of date).

Other large projects do this kind of thing; we need to see if there's any 
ideas/code we can borrow rather than completely re-inventing the wheel.

Again, these are just my thoughts after having thought about this for only 
about 30 minutes -- so this is likely quite rough and may not even resemble 
what we finally end up with.


On May 15, 2014, at 8:51 AM, Noam Bernstein  wrote:


I’m not sure how this would apply to other options, but for the scheduler, what 
about no scheduler-related options defaults to everything enabled (like 
before), but having any explicit scheduler enable option disables by default 
all the other schedulers? Multiple explicit enable options would enable all the 
requested schedulers, and disable everything else.


Noam
___
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users

Re: [OMPI users] Question about scheduler support

2014-05-15 Thread Jeff Squyres (jsquyres)

These are all good points -- thanks for the feedback.

Just to be clear: my point about the menu system was to generate file that 
could be used for subsequent installs, very specifically targeted at those who 
want/need scriptable installations.  

One possible scenario could be: you download OMPI, run the menu installer so 
that you can see the options that are available, pick the ones you want, 
generate the file, and then use it in automated installs (e.g., ./configure 
--only-build-this-stuff=file_I_created_from_menu_installer).  

I am presuming that the generated file will be text, so it could be 
built/edited by hand, too.  This is heavily inspired by the Linux kernel's 
"make menuconfig": it generates a .config file that you can use for subsequent 
builds.

We can also look at the possibility of providing a template file that lists all 
options that are available in that particular tarball (similar to the Linux 
kernel "make config").  

This, BTW, is one part where we need to build some new infrastructure: to 
register and discover all available options (history has shown that just 
maintaining a text file for a project the size of Open MPI is not feasible -- 
it'll get stale/out of date).  

Other large projects do this kind of thing; we need to see if there's any 
ideas/code we can borrow rather than completely re-inventing the wheel.

Again, these are just my thoughts after having thought about this for only 
about 30 minutes -- so this is likely quite rough and may not even resemble 
what we finally end up with.

On May 15, 2014, at 8:51 AM, Noam Bernstein  wrote:

> I’m not sure how this would apply to other options, but for the scheduler, 
> what about no scheduler-related options defaults to everything enabled (like 
> before), but having any explicit scheduler enable option disables by default 
> all the other schedulers? Multiple explicit enable options would enable all 
> the requested schedulers, and disable everything else.
> 
>   
> Noam
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI users] Question about scheduler support

2014-05-15 Thread Noam Bernstein

I’m not sure how this would apply to other options, but for the scheduler, what 
about no scheduler-related options defaults to everything enabled (like 
before), but having any explicit scheduler enable option disables by default 
all the other schedulers? Multiple explicit enable options would enable all the 
requested schedulers, and disable everything else.


Noam

Re: [OMPI users] Question about scheduler support

A file would do the trick, but from my experience of building programs, 
I always prefer configure options. Maybe just an option

--disable-optional

that disables anything that is optional and non-explicitely requested.

Maxime

Le 2014-05-15 08:22, Bennet Fauber a écrit :

Would a separate file that contains each scheduler option and is
included by configure do the trick?  It might read

include-slurm=YES
include-torque=YES
etc.

If all options are set to default to YES, then the people who want no
options are satisfied, but those of us who would like to change the
config would have an easy and scriptable way to change the option
using sed or whatever.

I agree with Maxime about requiring an interactive system to turn
things off.  It makes things difficult to script and document exactly
what was done.  I think providing the kitchen sink is fine for
default, but a simple switch or config file that flips it to including
nothing that wasn't requested might satisfy the other side.

I suspect that something similar would (or could) be part of a menu
configuration scheme, so the menu could be tacked on later, if it
turns out to be desired, and the menu would just modify the list of
things to build, so any work toward that scheme might not be lost.

-- bennet



On Thu, May 15, 2014 at 7:41 AM, Maxime Boissonneault
 wrote:

Le 2014-05-15 06:29, Jeff Squyres (jsquyres) a écrit :

I think Ralph's email summed it up pretty well -- we unfortunately have
(at least) two distinct groups of people who install OMPI:

a) those who know exactly what they want and don't want anything else
b) those who don't know exactly what they want and prefer to have
everything installed, and have OMPI auto-select at run time exactly what to
use based on the system on which it's running

We've traditionally catered to the b) crowd, and made some
not-very-easy-to-use capabilities for the a) crowd (i.e., you can manually
disable each plugin you don't want to build via configure, but the syntax is
fairly laborious).

Ralph and I talked about the possibility of something analogous to "make
menuconfig" for Linux kernels, where you get a menu-like system (UI TBD) to
pick exactly what options you want/don't want.  That will output a text
config file that can be fed to configure, something along the lines of

./configure --only-build-exactly-this-stuff=file-output-from-menuconfig

This idea is *very* rough; I anticipate that it will change quite a bit
over time, and it'll take us a bit of time to design and implement it.

A menu-like system is not going to be very useful at least for us, since we
script all of our installations. Scripting a menu is not very handy.

Maxime




On May 14, 2014, at 8:56 PM, Bennet Fauber  wrote:


I think Maxime's suggestion is sane and reasonable.  Just in case
you're taking ha'penny's worth from the groundlings.  I think I would
prefer not to have capability included that we won't use.

-- bennet



On Wed, May 14, 2014 at 7:43 PM, Maxime Boissonneault
 wrote:

For the scheduler issue, I would be happy with something like, if I ask
for
support for X, disable support for Y, Z and W. I am assuming that very
rarely will someone use more than one scheduler.

Maxime

Le 2014-05-14 19:09, Ralph Castain a écrit :

Jeff and I have talked about this and are approaching a compromise.
Still
more thinking to do, perhaps providing new configure options to "only
build
what I ask for" and/or a tool to support a menu-driven selection of
what to
build - as opposed to today's "build everything you don't tell me to
not-build"

Tough set of compromises as it depends on the target audience. Sys
admins
prefer the "build only what I say", while users (who frequently aren't
that
familiar with the inners of a system) prefer the "build all" mentality.


On May 14, 2014, at 3:16 PM, Ralph Castain  wrote:


Indeed, a quick review indicates that the new policy for scheduler
support was not uniformly applied. I'll update it.

To reiterate: we will only build support for a scheduler if the user
specifically requests it. We did this because we are increasingly
seeing
distros include header support for various schedulers, and so just
finding
the required headers isn't enough to know that the scheduler is
intended for
use. So we wind up building a bunch of useless modules.


On May 14, 2014, at 3:09 PM, Ralph Castain  wrote:


FWIW: I believe we no longer build the slurm support by default,
though
I'd have to check to be sure. The intent is definitely not to do so.

The plan we adjusted to a while back was to *only* build support for
schedulers upon request. Can't swear that they are all correctly
updated,
but that was the intent.


On May 14, 2014, at 2:52 PM, Jeff Squyres (jsquyres)
 wrote:


Here's a bit of our rational, from the README file:

   Note that for many of Open MPI's --with- options, Open MPI
will,
   by default, search for header files and/or libraries for .
If
   the relevant files are found, Open MPI will built support for

Re: [OMPI users] Question about scheduler support

2014-05-15 Thread Bennet Fauber

Would a separate file that contains each scheduler option and is
included by configure do the trick?  It might read

include-slurm=YES
include-torque=YES
etc.

If all options are set to default to YES, then the people who want no
options are satisfied, but those of us who would like to change the
config would have an easy and scriptable way to change the option
using sed or whatever.

I agree with Maxime about requiring an interactive system to turn
things off.  It makes things difficult to script and document exactly
what was done.  I think providing the kitchen sink is fine for
default, but a simple switch or config file that flips it to including
nothing that wasn't requested might satisfy the other side.

I suspect that something similar would (or could) be part of a menu
configuration scheme, so the menu could be tacked on later, if it
turns out to be desired, and the menu would just modify the list of
things to build, so any work toward that scheme might not be lost.

-- bennet



On Thu, May 15, 2014 at 7:41 AM, Maxime Boissonneault
 wrote:
> Le 2014-05-15 06:29, Jeff Squyres (jsquyres) a écrit :
>>
>> I think Ralph's email summed it up pretty well -- we unfortunately have
>> (at least) two distinct groups of people who install OMPI:
>>
>> a) those who know exactly what they want and don't want anything else
>> b) those who don't know exactly what they want and prefer to have
>> everything installed, and have OMPI auto-select at run time exactly what to
>> use based on the system on which it's running
>>
>> We've traditionally catered to the b) crowd, and made some
>> not-very-easy-to-use capabilities for the a) crowd (i.e., you can manually
>> disable each plugin you don't want to build via configure, but the syntax is
>> fairly laborious).
>>
>> Ralph and I talked about the possibility of something analogous to "make
>> menuconfig" for Linux kernels, where you get a menu-like system (UI TBD) to
>> pick exactly what options you want/don't want.  That will output a text
>> config file that can be fed to configure, something along the lines of
>>
>>./configure --only-build-exactly-this-stuff=file-output-from-menuconfig
>>
>> This idea is *very* rough; I anticipate that it will change quite a bit
>> over time, and it'll take us a bit of time to design and implement it.
>
> A menu-like system is not going to be very useful at least for us, since we
> script all of our installations. Scripting a menu is not very handy.
>
> Maxime
>
>
>>
>>
>> On May 14, 2014, at 8:56 PM, Bennet Fauber  wrote:
>>
>>> I think Maxime's suggestion is sane and reasonable.  Just in case
>>> you're taking ha'penny's worth from the groundlings.  I think I would
>>> prefer not to have capability included that we won't use.
>>>
>>> -- bennet
>>>
>>>
>>>
>>> On Wed, May 14, 2014 at 7:43 PM, Maxime Boissonneault
>>>  wrote:

 For the scheduler issue, I would be happy with something like, if I ask
 for
 support for X, disable support for Y, Z and W. I am assuming that very
 rarely will someone use more than one scheduler.

 Maxime

 Le 2014-05-14 19:09, Ralph Castain a écrit :
>
> Jeff and I have talked about this and are approaching a compromise.
> Still
> more thinking to do, perhaps providing new configure options to "only
> build
> what I ask for" and/or a tool to support a menu-driven selection of
> what to
> build - as opposed to today's "build everything you don't tell me to
> not-build"
>
> Tough set of compromises as it depends on the target audience. Sys
> admins
> prefer the "build only what I say", while users (who frequently aren't
> that
> familiar with the inners of a system) prefer the "build all" mentality.
>
>
> On May 14, 2014, at 3:16 PM, Ralph Castain  wrote:
>
>> Indeed, a quick review indicates that the new policy for scheduler
>> support was not uniformly applied. I'll update it.
>>
>> To reiterate: we will only build support for a scheduler if the user
>> specifically requests it. We did this because we are increasingly
>> seeing
>> distros include header support for various schedulers, and so just
>> finding
>> the required headers isn't enough to know that the scheduler is
>> intended for
>> use. So we wind up building a bunch of useless modules.
>>
>>
>> On May 14, 2014, at 3:09 PM, Ralph Castain  wrote:
>>
>>> FWIW: I believe we no longer build the slurm support by default,
>>> though
>>> I'd have to check to be sure. The intent is definitely not to do so.
>>>
>>> The plan we adjusted to a while back was to *only* build support for
>>> schedulers upon request. Can't swear that they are all correctly
>>> updated,
>>> but that was the intent.
>>>
>>>
>>> On May 14, 2014, at 2:52 PM, Jeff Squyres (jsquyres)
>>>  wrote:
>>>
 Here's a bit of our rational, from the README file:

Re: [OMPI users] Question about scheduler support


Le 2014-05-15 06:29, Jeff Squyres (jsquyres) a écrit :

I think Ralph's email summed it up pretty well -- we unfortunately have (at 
least) two distinct groups of people who install OMPI:

a) those who know exactly what they want and don't want anything else
b) those who don't know exactly what they want and prefer to have everything 
installed, and have OMPI auto-select at run time exactly what to use based on 
the system on which it's running

We've traditionally catered to the b) crowd, and made some not-very-easy-to-use 
capabilities for the a) crowd (i.e., you can manually disable each plugin you 
don't want to build via configure, but the syntax is fairly laborious).

Ralph and I talked about the possibility of something analogous to "make 
menuconfig" for Linux kernels, where you get a menu-like system (UI TBD) to pick 
exactly what options you want/don't want.  That will output a text config file that can 
be fed to configure, something along the lines of

   ./configure --only-build-exactly-this-stuff=file-output-from-menuconfig

This idea is *very* rough; I anticipate that it will change quite a bit over 
time, and it'll take us a bit of time to design and implement it.
A menu-like system is not going to be very useful at least for us, since 
we script all of our installations. Scripting a menu is not very handy.


Maxime





On May 14, 2014, at 8:56 PM, Bennet Fauber  wrote:


I think Maxime's suggestion is sane and reasonable.  Just in case
you're taking ha'penny's worth from the groundlings.  I think I would
prefer not to have capability included that we won't use.

-- bennet



On Wed, May 14, 2014 at 7:43 PM, Maxime Boissonneault
 wrote:

For the scheduler issue, I would be happy with something like, if I ask for
support for X, disable support for Y, Z and W. I am assuming that very
rarely will someone use more than one scheduler.

Maxime

Le 2014-05-14 19:09, Ralph Castain a écrit :

Jeff and I have talked about this and are approaching a compromise.  Still
more thinking to do, perhaps providing new configure options to "only build
what I ask for" and/or a tool to support a menu-driven selection of what to
build - as opposed to today's "build everything you don't tell me to
not-build"

Tough set of compromises as it depends on the target audience. Sys admins
prefer the "build only what I say", while users (who frequently aren't that
familiar with the inners of a system) prefer the "build all" mentality.


On May 14, 2014, at 3:16 PM, Ralph Castain  wrote:


Indeed, a quick review indicates that the new policy for scheduler
support was not uniformly applied. I'll update it.

To reiterate: we will only build support for a scheduler if the user
specifically requests it. We did this because we are increasingly seeing
distros include header support for various schedulers, and so just finding
the required headers isn't enough to know that the scheduler is intended for
use. So we wind up building a bunch of useless modules.


On May 14, 2014, at 3:09 PM, Ralph Castain  wrote:


FWIW: I believe we no longer build the slurm support by default, though
I'd have to check to be sure. The intent is definitely not to do so.

The plan we adjusted to a while back was to *only* build support for
schedulers upon request. Can't swear that they are all correctly updated,
but that was the intent.


On May 14, 2014, at 2:52 PM, Jeff Squyres (jsquyres)
 wrote:


Here's a bit of our rational, from the README file:

  Note that for many of Open MPI's --with- options, Open MPI will,
  by default, search for header files and/or libraries for .  If
  the relevant files are found, Open MPI will built support for ;
  if they are not found, Open MPI will skip building support for .
  However, if you specify --with- on the configure command line
and
  Open MPI is unable to find relevant support for , configure will
  assume that it was unable to provide a feature that was specifically
  requested and will abort so that a human can resolve out the issue.

In some cases, we don't need header or library files.  For example,
with SLURM and LSF, our native support is actually just fork/exec'ing the
SLURM/LSF executables under the covers (e.g., as opposed to using rsh/ssh).
So we can basically *always* build them.  So we do.

In general, OMPI builds support for everything that it can find on the
rationale that a) we can't know ahead of time exactly what people want, and
b) most people want to just "./configure && make -j 32 install" and be done
with it -- so build as much as possible.


On May 14, 2014, at 5:31 PM, Maxime Boissonneault
 wrote:


Hi Gus,
Oh, I know that, what I am refering to is that slurm and loadleveler
support are enabled by default, and it seems that if we're using
Torque/Moab, we have no use for slurm and loadleveler support.

My point is not that it is hard to compile it with torque support, my
point is that it is compiling support for many schedulers while I'm rather
convinced that very few sites actuall

Re: [OMPI users] Question about scheduler support

2014-05-15 Thread Jeff Squyres (jsquyres)

I think Ralph's email summed it up pretty well -- we unfortunately have (at 
least) two distinct groups of people who install OMPI:

a) those who know exactly what they want and don't want anything else
b) those who don't know exactly what they want and prefer to have everything 
installed, and have OMPI auto-select at run time exactly what to use based on 
the system on which it's running

We've traditionally catered to the b) crowd, and made some not-very-easy-to-use 
capabilities for the a) crowd (i.e., you can manually disable each plugin you 
don't want to build via configure, but the syntax is fairly laborious).

Ralph and I talked about the possibility of something analogous to "make 
menuconfig" for Linux kernels, where you get a menu-like system (UI TBD) to 
pick exactly what options you want/don't want.  That will output a text config 
file that can be fed to configure, something along the lines of

  ./configure --only-build-exactly-this-stuff=file-output-from-menuconfig

This idea is *very* rough; I anticipate that it will change quite a bit over 
time, and it'll take us a bit of time to design and implement it.



On May 14, 2014, at 8:56 PM, Bennet Fauber  wrote:

> I think Maxime's suggestion is sane and reasonable.  Just in case
> you're taking ha'penny's worth from the groundlings.  I think I would
> prefer not to have capability included that we won't use.
> 
> -- bennet
> 
> 
> 
> On Wed, May 14, 2014 at 7:43 PM, Maxime Boissonneault
>  wrote:
>> For the scheduler issue, I would be happy with something like, if I ask for
>> support for X, disable support for Y, Z and W. I am assuming that very
>> rarely will someone use more than one scheduler.
>> 
>> Maxime
>> 
>> Le 2014-05-14 19:09, Ralph Castain a écrit :
>>> 
>>> Jeff and I have talked about this and are approaching a compromise.  Still
>>> more thinking to do, perhaps providing new configure options to "only build
>>> what I ask for" and/or a tool to support a menu-driven selection of what to
>>> build - as opposed to today's "build everything you don't tell me to
>>> not-build"
>>> 
>>> Tough set of compromises as it depends on the target audience. Sys admins
>>> prefer the "build only what I say", while users (who frequently aren't that
>>> familiar with the inners of a system) prefer the "build all" mentality.
>>> 
>>> 
>>> On May 14, 2014, at 3:16 PM, Ralph Castain  wrote:
>>> 
 Indeed, a quick review indicates that the new policy for scheduler
 support was not uniformly applied. I'll update it.
 
 To reiterate: we will only build support for a scheduler if the user
 specifically requests it. We did this because we are increasingly seeing
 distros include header support for various schedulers, and so just finding
 the required headers isn't enough to know that the scheduler is intended 
 for
 use. So we wind up building a bunch of useless modules.
 
 
 On May 14, 2014, at 3:09 PM, Ralph Castain  wrote:
 
> FWIW: I believe we no longer build the slurm support by default, though
> I'd have to check to be sure. The intent is definitely not to do so.
> 
> The plan we adjusted to a while back was to *only* build support for
> schedulers upon request. Can't swear that they are all correctly updated,
> but that was the intent.
> 
> 
> On May 14, 2014, at 2:52 PM, Jeff Squyres (jsquyres)
>  wrote:
> 
>> Here's a bit of our rational, from the README file:
>> 
>>  Note that for many of Open MPI's --with- options, Open MPI will,
>>  by default, search for header files and/or libraries for .  If
>>  the relevant files are found, Open MPI will built support for ;
>>  if they are not found, Open MPI will skip building support for .
>>  However, if you specify --with- on the configure command line
>> and
>>  Open MPI is unable to find relevant support for , configure will
>>  assume that it was unable to provide a feature that was specifically
>>  requested and will abort so that a human can resolve out the issue.
>> 
>> In some cases, we don't need header or library files.  For example,
>> with SLURM and LSF, our native support is actually just fork/exec'ing the
>> SLURM/LSF executables under the covers (e.g., as opposed to using 
>> rsh/ssh).
>> So we can basically *always* build them.  So we do.
>> 
>> In general, OMPI builds support for everything that it can find on the
>> rationale that a) we can't know ahead of time exactly what people want, 
>> and
>> b) most people want to just "./configure && make -j 32 install" and be 
>> done
>> with it -- so build as much as possible.
>> 
>> 
>> On May 14, 2014, at 5:31 PM, Maxime Boissonneault
>>  wrote:
>> 
>>> Hi Gus,
>>> Oh, I know that, what I am refering to is that slurm and loadleveler
>>> support are enabled by default, and it seems that if we're using
>>> Torque/M

Re: [OMPI users] Question about scheduler support

2014-05-14 Thread Bennet Fauber

I think Maxime's suggestion is sane and reasonable.  Just in case
you're taking ha'penny's worth from the groundlings.  I think I would
prefer not to have capability included that we won't use.

-- bennet



On Wed, May 14, 2014 at 7:43 PM, Maxime Boissonneault
 wrote:
> For the scheduler issue, I would be happy with something like, if I ask for
> support for X, disable support for Y, Z and W. I am assuming that very
> rarely will someone use more than one scheduler.
>
> Maxime
>
> Le 2014-05-14 19:09, Ralph Castain a écrit :
>>
>> Jeff and I have talked about this and are approaching a compromise.  Still
>> more thinking to do, perhaps providing new configure options to "only build
>> what I ask for" and/or a tool to support a menu-driven selection of what to
>> build - as opposed to today's "build everything you don't tell me to
>> not-build"
>>
>> Tough set of compromises as it depends on the target audience. Sys admins
>> prefer the "build only what I say", while users (who frequently aren't that
>> familiar with the inners of a system) prefer the "build all" mentality.
>>
>>
>> On May 14, 2014, at 3:16 PM, Ralph Castain  wrote:
>>
>>> Indeed, a quick review indicates that the new policy for scheduler
>>> support was not uniformly applied. I'll update it.
>>>
>>> To reiterate: we will only build support for a scheduler if the user
>>> specifically requests it. We did this because we are increasingly seeing
>>> distros include header support for various schedulers, and so just finding
>>> the required headers isn't enough to know that the scheduler is intended for
>>> use. So we wind up building a bunch of useless modules.
>>>
>>>
>>> On May 14, 2014, at 3:09 PM, Ralph Castain  wrote:
>>>
 FWIW: I believe we no longer build the slurm support by default, though
 I'd have to check to be sure. The intent is definitely not to do so.

 The plan we adjusted to a while back was to *only* build support for
 schedulers upon request. Can't swear that they are all correctly updated,
 but that was the intent.


 On May 14, 2014, at 2:52 PM, Jeff Squyres (jsquyres)
  wrote:

> Here's a bit of our rational, from the README file:
>
>   Note that for many of Open MPI's --with- options, Open MPI will,
>   by default, search for header files and/or libraries for .  If
>   the relevant files are found, Open MPI will built support for ;
>   if they are not found, Open MPI will skip building support for .
>   However, if you specify --with- on the configure command line
> and
>   Open MPI is unable to find relevant support for , configure will
>   assume that it was unable to provide a feature that was specifically
>   requested and will abort so that a human can resolve out the issue.
>
> In some cases, we don't need header or library files.  For example,
> with SLURM and LSF, our native support is actually just fork/exec'ing the
> SLURM/LSF executables under the covers (e.g., as opposed to using 
> rsh/ssh).
> So we can basically *always* build them.  So we do.
>
> In general, OMPI builds support for everything that it can find on the
> rationale that a) we can't know ahead of time exactly what people want, 
> and
> b) most people want to just "./configure && make -j 32 install" and be 
> done
> with it -- so build as much as possible.
>
>
> On May 14, 2014, at 5:31 PM, Maxime Boissonneault
>  wrote:
>
>> Hi Gus,
>> Oh, I know that, what I am refering to is that slurm and loadleveler
>> support are enabled by default, and it seems that if we're using
>> Torque/Moab, we have no use for slurm and loadleveler support.
>>
>> My point is not that it is hard to compile it with torque support, my
>> point is that it is compiling support for many schedulers while I'm 
>> rather
>> convinced that very few sites actually use multiple schedulers at the 
>> same
>> time.
>>
>>
>> Maxime
>>
>> Le 2014-05-14 16:51, Gus Correa a écrit :
>>>
>>> On 05/14/2014 04:25 PM, Maxime Boissonneault wrote:

 Hi,
 I was compiling OpenMPI 1.8.1 today and I noticed that pretty much
 every
 single scheduler has its support enabled by default at configure
 (except
 the one I need, which is Torque). Is there a reason for that ? Why
 not
 have a single scheduler enabled and require to specify it at
 configure
 time ?

 Is there any reason for me to build with loadlever or slurm if we're
 using torque ?

 Thanks,

 Maxime Boisssonneault
>>>
>>> Hi Maxime
>>>
>>> I haven't tried 1.8.1 yet.
>>> However, for all previous versions of OMPI I tried, up to 1.6.5,
>>> all it took to configure it with Torque support was to point
>>> configure
>>> to the Torque ins

Re: [OMPI users] Question about scheduler support

Good point - will see what we can do about it.


On May 14, 2014, at 4:43 PM, Maxime Boissonneault 
 wrote:

> For the scheduler issue, I would be happy with something like, if I ask for 
> support for X, disable support for Y, Z and W. I am assuming that very rarely 
> will someone use more than one scheduler.
> 
> Maxime
> 
> Le 2014-05-14 19:09, Ralph Castain a écrit :
>> Jeff and I have talked about this and are approaching a compromise.  Still 
>> more thinking to do, perhaps providing new configure options to "only build 
>> what I ask for" and/or a tool to support a menu-driven selection of what to 
>> build - as opposed to today's "build everything you don't tell me to 
>> not-build"
>> 
>> Tough set of compromises as it depends on the target audience. Sys admins 
>> prefer the "build only what I say", while users (who frequently aren't that 
>> familiar with the inners of a system) prefer the "build all" mentality.
>> 
>> 
>> On May 14, 2014, at 3:16 PM, Ralph Castain  wrote:
>> 
>>> Indeed, a quick review indicates that the new policy for scheduler support 
>>> was not uniformly applied. I'll update it.
>>> 
>>> To reiterate: we will only build support for a scheduler if the user 
>>> specifically requests it. We did this because we are increasingly seeing 
>>> distros include header support for various schedulers, and so just finding 
>>> the required headers isn't enough to know that the scheduler is intended 
>>> for use. So we wind up building a bunch of useless modules.
>>> 
>>> 
>>> On May 14, 2014, at 3:09 PM, Ralph Castain  wrote:
>>> 
 FWIW: I believe we no longer build the slurm support by default, though 
 I'd have to check to be sure. The intent is definitely not to do so.
 
 The plan we adjusted to a while back was to *only* build support for 
 schedulers upon request. Can't swear that they are all correctly updated, 
 but that was the intent.
 
 
 On May 14, 2014, at 2:52 PM, Jeff Squyres (jsquyres)  
 wrote:
 
> Here's a bit of our rational, from the README file:
> 
>  Note that for many of Open MPI's --with- options, Open MPI will,
>  by default, search for header files and/or libraries for .  If
>  the relevant files are found, Open MPI will built support for ;
>  if they are not found, Open MPI will skip building support for .
>  However, if you specify --with- on the configure command line and
>  Open MPI is unable to find relevant support for , configure will
>  assume that it was unable to provide a feature that was specifically
>  requested and will abort so that a human can resolve out the issue.
> 
> In some cases, we don't need header or library files.  For example, with 
> SLURM and LSF, our native support is actually just fork/exec'ing the 
> SLURM/LSF executables under the covers (e.g., as opposed to using 
> rsh/ssh).  So we can basically *always* build them.  So we do.
> 
> In general, OMPI builds support for everything that it can find on the 
> rationale that a) we can't know ahead of time exactly what people want, 
> and b) most people want to just "./configure && make -j 32 install" and 
> be done with it -- so build as much as possible.
> 
> 
> On May 14, 2014, at 5:31 PM, Maxime Boissonneault 
>  wrote:
> 
>> Hi Gus,
>> Oh, I know that, what I am refering to is that slurm and loadleveler 
>> support are enabled by default, and it seems that if we're using 
>> Torque/Moab, we have no use for slurm and loadleveler support.
>> 
>> My point is not that it is hard to compile it with torque support, my 
>> point is that it is compiling support for many schedulers while I'm 
>> rather convinced that very few sites actually use multiple schedulers at 
>> the same time.
>> 
>> 
>> Maxime
>> 
>> Le 2014-05-14 16:51, Gus Correa a écrit :
>>> On 05/14/2014 04:25 PM, Maxime Boissonneault wrote:
 Hi,
 I was compiling OpenMPI 1.8.1 today and I noticed that pretty much 
 every
 single scheduler has its support enabled by default at configure 
 (except
 the one I need, which is Torque). Is there a reason for that ? Why not
 have a single scheduler enabled and require to specify it at configure
 time ?
 
 Is there any reason for me to build with loadlever or slurm if we're
 using torque ?
 
 Thanks,
 
 Maxime Boisssonneault
>>> Hi Maxime
>>> 
>>> I haven't tried 1.8.1 yet.
>>> However, for all previous versions of OMPI I tried, up to 1.6.5,
>>> all it took to configure it with Torque support was to point configure
>>> to the Torque installation directory (which is non-standard in my case):
>>> 
>>> --with-tm=/opt/torque/bla/bla
>>> 
>>> My two cents,
>>> Gus Correa
>>> 
>>>

Re: [OMPI users] Question about scheduler support

2014-05-14 Thread Maxime Boissonneault

For the scheduler issue, I would be happy with something like, if I ask
for support for X, disable support for Y, Z and W. I am assuming that
very rarely will someone use more than one scheduler.

Maxime

Le 2014-05-14 19:09, Ralph Castain a écrit :

Jeff and I have talked about this and are approaching a compromise. Still more thinking to do,
perhaps providing new configure options to "only build what I ask for" and/or a tool to
support a menu-driven selection of what to build - as opposed to today's "build everything you
don't tell me to not-build"

Tough set of compromises as it depends on the target audience. Sys admins prefer the "build
only what I say", while users (who frequently aren't that familiar with the inners of a
system) prefer the "build all" mentality.

On May 14, 2014, at 3:16 PM, Ralph Castain wrote:

Indeed, a quick review indicates that the new policy for scheduler support was
not uniformly applied. I'll update it.

To reiterate: we will only build support for a scheduler if the user
specifically requests it. We did this because we are increasingly seeing
distros include header support for various schedulers, and so just finding the
required headers isn't enough to know that the scheduler is intended for use.
So we wind up building a bunch of useless modules.

On May 14, 2014, at 3:09 PM, Ralph Castain wrote:

FWIW: I believe we no longer build the slurm support by default, though I'd
have to check to be sure. The intent is definitely not to do so.

The plan we adjusted to a while back was to *only* build support for schedulers
upon request. Can't swear that they are all correctly updated, but that was the
intent.

On May 14, 2014, at 2:52 PM, Jeff Squyres (jsquyres) wrote:

Here's a bit of our rational, from the README file:

Note that for many of Open MPI's --with- options, Open MPI will,
by default, search for header files and/or libraries for . If
the relevant files are found, Open MPI will built support for ;
if they are not found, Open MPI will skip building support for .
However, if you specify --with- on the configure command line and
Open MPI is unable to find relevant support for , configure will
assume that it was unable to provide a feature that was specifically
requested and will abort so that a human can resolve out the issue.

In some cases, we don't need header or library files. For example, with SLURM
and LSF, our native support is actually just fork/exec'ing the SLURM/LSF
executables under the covers (e.g., as opposed to using rsh/ssh). So we can
basically *always* build them. So we do.

In general, OMPI builds support for everything that it can find on the rationale that a) we can't
know ahead of time exactly what people want, and b) most people want to just "./configure
&& make -j 32 install" and be done with it -- so build as much as possible.

On May 14, 2014, at 5:31 PM, Maxime Boissonneault
wrote:

Hi Gus,
Oh, I know that, what I am refering to is that slurm and loadleveler support
are enabled by default, and it seems that if we're using Torque/Moab, we have
no use for slurm and loadleveler support.

My point is not that it is hard to compile it with torque support, my point is
that it is compiling support for many schedulers while I'm rather convinced
that very few sites actually use multiple schedulers at the same time.

Maxime

Le 2014-05-14 16:51, Gus Correa a écrit :

On 05/14/2014 04:25 PM, Maxime Boissonneault wrote:

Hi,
I was compiling OpenMPI 1.8.1 today and I noticed that pretty much every
single scheduler has its support enabled by default at configure (except
the one I need, which is Torque). Is there a reason for that ? Why not
have a single scheduler enabled and require to specify it at configure
time ?

Is there any reason for me to build with loadlever or slurm if we're
using torque ?

Thanks,

Maxime Boisssonneault

Hi Maxime

I haven't tried 1.8.1 yet.
However, for all previous versions of OMPI I tried, up to 1.6.5,
all it took to configure it with Torque support was to point configure
to the Torque installation directory (which is non-standard in my case):

--with-tm=/opt/torque/bla/bla

My two cents,
Gus Correa

___
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users

--
-
Maxime Boissonneault
Analyste de calcul - Calcul Québec, Université Laval
Ph. D. en physique

___
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users

--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/

___
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users

___
users mailing list
us...@open-mpi.org
http://www.open-mpi

Re: [OMPI users] Question about scheduler support

Jeff and I have talked about this and are approaching a compromise.  Still more 
thinking to do, perhaps providing new configure options to "only build what I 
ask for" and/or a tool to support a menu-driven selection of what to build - as 
opposed to today's "build everything you don't tell me to not-build"

Tough set of compromises as it depends on the target audience. Sys admins 
prefer the "build only what I say", while users (who frequently aren't that 
familiar with the inners of a system) prefer the "build all" mentality.


On May 14, 2014, at 3:16 PM, Ralph Castain  wrote:

> Indeed, a quick review indicates that the new policy for scheduler support 
> was not uniformly applied. I'll update it.
> 
> To reiterate: we will only build support for a scheduler if the user 
> specifically requests it. We did this because we are increasingly seeing 
> distros include header support for various schedulers, and so just finding 
> the required headers isn't enough to know that the scheduler is intended for 
> use. So we wind up building a bunch of useless modules.
> 
> 
> On May 14, 2014, at 3:09 PM, Ralph Castain  wrote:
> 
>> FWIW: I believe we no longer build the slurm support by default, though I'd 
>> have to check to be sure. The intent is definitely not to do so.
>> 
>> The plan we adjusted to a while back was to *only* build support for 
>> schedulers upon request. Can't swear that they are all correctly updated, 
>> but that was the intent.
>> 
>> 
>> On May 14, 2014, at 2:52 PM, Jeff Squyres (jsquyres)  
>> wrote:
>> 
>>> Here's a bit of our rational, from the README file:
>>> 
>>>  Note that for many of Open MPI's --with- options, Open MPI will,
>>>  by default, search for header files and/or libraries for .  If
>>>  the relevant files are found, Open MPI will built support for ;
>>>  if they are not found, Open MPI will skip building support for .
>>>  However, if you specify --with- on the configure command line and
>>>  Open MPI is unable to find relevant support for , configure will
>>>  assume that it was unable to provide a feature that was specifically
>>>  requested and will abort so that a human can resolve out the issue.
>>> 
>>> In some cases, we don't need header or library files.  For example, with 
>>> SLURM and LSF, our native support is actually just fork/exec'ing the 
>>> SLURM/LSF executables under the covers (e.g., as opposed to using rsh/ssh). 
>>>  So we can basically *always* build them.  So we do.
>>> 
>>> In general, OMPI builds support for everything that it can find on the 
>>> rationale that a) we can't know ahead of time exactly what people want, and 
>>> b) most people want to just "./configure && make -j 32 install" and be done 
>>> with it -- so build as much as possible.
>>> 
>>> 
>>> On May 14, 2014, at 5:31 PM, Maxime Boissonneault 
>>>  wrote:
>>> 
 Hi Gus,
 Oh, I know that, what I am refering to is that slurm and loadleveler 
 support are enabled by default, and it seems that if we're using 
 Torque/Moab, we have no use for slurm and loadleveler support.
 
 My point is not that it is hard to compile it with torque support, my 
 point is that it is compiling support for many schedulers while I'm rather 
 convinced that very few sites actually use multiple schedulers at the same 
 time.
 
 
 Maxime
 
 Le 2014-05-14 16:51, Gus Correa a écrit :
> On 05/14/2014 04:25 PM, Maxime Boissonneault wrote:
>> Hi,
>> I was compiling OpenMPI 1.8.1 today and I noticed that pretty much every
>> single scheduler has its support enabled by default at configure (except
>> the one I need, which is Torque). Is there a reason for that ? Why not
>> have a single scheduler enabled and require to specify it at configure
>> time ?
>> 
>> Is there any reason for me to build with loadlever or slurm if we're
>> using torque ?
>> 
>> Thanks,
>> 
>> Maxime Boisssonneault
> 
> Hi Maxime
> 
> I haven't tried 1.8.1 yet.
> However, for all previous versions of OMPI I tried, up to 1.6.5,
> all it took to configure it with Torque support was to point configure
> to the Torque installation directory (which is non-standard in my case):
> 
> --with-tm=/opt/torque/bla/bla
> 
> My two cents,
> Gus Correa
> 
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users
 
 
 -- 
 -
 Maxime Boissonneault
 Analyste de calcul - Calcul Québec, Université Laval
 Ph. D. en physique
 
 ___
 users mailing list
 us...@open-mpi.org
 http://www.open-mpi.org/mailman/listinfo.cgi/users
>>> 
>>> 
>>> -- 
>>> Jeff Squyres
>>> jsquy...@cisco.com
>>> For corporate legal information go to: 
>>> http://www.cisco.com/web/about/doing_business/lega

Re: [OMPI users] Question about scheduler support

On May 14, 2014, at 3:21 PM, Jeff Squyres (jsquyres)  wrote:

> On May 14, 2014, at 6:09 PM, Ralph Castain  wrote:
> 
>> FWIW: I believe we no longer build the slurm support by default, though I'd 
>> have to check to be sure. The intent is definitely not to do so.
> 
> The srun-based support builds by default.  I like it that way.  :-)

Yeah, because you actually use Slurm - but that isn't much comfort to all those 
who don't, but still get a slurm module.

> 
> PMI-based support is a different animal, right?

Yes, it is.

> 
>> The plan we adjusted to a while back was to *only* build support for 
>> schedulers upon request. Can't swear that they are all correctly updated, 
>> but that was the intent.
> 
> Why would we do that?  I'm all for a minimal ./configure line... did I miss 
> something?

As per my other note, we are getting a continually increasing number of 
"default" builds due to included files in the distro when there is zero intent 
to actually install/use the scheduler.

> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> ___
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users

Re: [OMPI users] Question about scheduler support

2014-05-14 Thread Jeff Squyres (jsquyres)

On May 14, 2014, at 6:09 PM, Ralph Castain  wrote:

> FWIW: I believe we no longer build the slurm support by default, though I'd 
> have to check to be sure. The intent is definitely not to do so.

The srun-based support builds by default.  I like it that way.  :-)

PMI-based support is a different animal, right?

> The plan we adjusted to a while back was to *only* build support for 
> schedulers upon request. Can't swear that they are all correctly updated, but 
> that was the intent.

Why would we do that?  I'm all for a minimal ./configure line... did I miss 
something?

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/

Re: [OMPI users] Question about scheduler support

Indeed, a quick review indicates that the new policy for scheduler support was 
not uniformly applied. I'll update it.

To reiterate: we will only build support for a scheduler if the user 
specifically requests it. We did this because we are increasingly seeing 
distros include header support for various schedulers, and so just finding the 
required headers isn't enough to know that the scheduler is intended for use. 
So we wind up building a bunch of useless modules.


On May 14, 2014, at 3:09 PM, Ralph Castain  wrote:

> FWIW: I believe we no longer build the slurm support by default, though I'd 
> have to check to be sure. The intent is definitely not to do so.
> 
> The plan we adjusted to a while back was to *only* build support for 
> schedulers upon request. Can't swear that they are all correctly updated, but 
> that was the intent.
> 
> 
> On May 14, 2014, at 2:52 PM, Jeff Squyres (jsquyres)  
> wrote:
> 
>> Here's a bit of our rational, from the README file:
>> 
>>   Note that for many of Open MPI's --with- options, Open MPI will,
>>   by default, search for header files and/or libraries for .  If
>>   the relevant files are found, Open MPI will built support for ;
>>   if they are not found, Open MPI will skip building support for .
>>   However, if you specify --with- on the configure command line and
>>   Open MPI is unable to find relevant support for , configure will
>>   assume that it was unable to provide a feature that was specifically
>>   requested and will abort so that a human can resolve out the issue.
>> 
>> In some cases, we don't need header or library files.  For example, with 
>> SLURM and LSF, our native support is actually just fork/exec'ing the 
>> SLURM/LSF executables under the covers (e.g., as opposed to using rsh/ssh).  
>> So we can basically *always* build them.  So we do.
>> 
>> In general, OMPI builds support for everything that it can find on the 
>> rationale that a) we can't know ahead of time exactly what people want, and 
>> b) most people want to just "./configure && make -j 32 install" and be done 
>> with it -- so build as much as possible.
>> 
>> 
>> On May 14, 2014, at 5:31 PM, Maxime Boissonneault 
>>  wrote:
>> 
>>> Hi Gus,
>>> Oh, I know that, what I am refering to is that slurm and loadleveler 
>>> support are enabled by default, and it seems that if we're using 
>>> Torque/Moab, we have no use for slurm and loadleveler support.
>>> 
>>> My point is not that it is hard to compile it with torque support, my point 
>>> is that it is compiling support for many schedulers while I'm rather 
>>> convinced that very few sites actually use multiple schedulers at the same 
>>> time.
>>> 
>>> 
>>> Maxime
>>> 
>>> Le 2014-05-14 16:51, Gus Correa a écrit :
 On 05/14/2014 04:25 PM, Maxime Boissonneault wrote:
> Hi,
> I was compiling OpenMPI 1.8.1 today and I noticed that pretty much every
> single scheduler has its support enabled by default at configure (except
> the one I need, which is Torque). Is there a reason for that ? Why not
> have a single scheduler enabled and require to specify it at configure
> time ?
> 
> Is there any reason for me to build with loadlever or slurm if we're
> using torque ?
> 
> Thanks,
> 
> Maxime Boisssonneault
 
 Hi Maxime
 
 I haven't tried 1.8.1 yet.
 However, for all previous versions of OMPI I tried, up to 1.6.5,
 all it took to configure it with Torque support was to point configure
 to the Torque installation directory (which is non-standard in my case):
 
 --with-tm=/opt/torque/bla/bla
 
 My two cents,
 Gus Correa
 
 ___
 users mailing list
 us...@open-mpi.org
 http://www.open-mpi.org/mailman/listinfo.cgi/users
>>> 
>>> 
>>> -- 
>>> -
>>> Maxime Boissonneault
>>> Analyste de calcul - Calcul Québec, Université Laval
>>> Ph. D. en physique
>>> 
>>> ___
>>> users mailing list
>>> us...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>> 
>> 
>> -- 
>> Jeff Squyres
>> jsquy...@cisco.com
>> For corporate legal information go to: 
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>> 
>> ___
>> users mailing list
>> us...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/users
>

Re: [OMPI users] Question about scheduler support