Re: [OMPI devel] mpirun alternative

2021-03-09 Thread George Bosilca via devel
Gabriel, Awesome, good luck. I have no idea which are or are not necessary for a proper functioning daemon. To me all of the ones you have here seem critical. Ralph would be a better source of information regarding the daemons' requirements. Thanks, George. On Tue, Mar 9, 2021 at 10:25 AM Ga

Re: [OMPI devel] mpirun alternative

2021-03-09 Thread Ralph Castain via devel
If you can launch that cmd line on each node, then it should work. I'm not sure what the "-x 10.0.35.43" at the beginning of the line is supposed to do, so that might not be useful. On Mar 9, 2021, at 7:25 AM, Gabriel Tanase mailto:gabrieltan...@gmail.com> > wrote: George, I started to digg m

Re: [OMPI devel] mpirun alternative

2021-03-09 Thread Gabriel Tanase via devel
George, I started to digg more in option 2 as you describe it. I believe I can make that work. For example I created this fake ssh : $ cat ~/bin/ssh #!/bin/bash fname=env.$$ echo "> ssh" >> $fname env >>$fname echo ">>>" >>$fname echo $@ >>$fname And this one p

Re: [OMPI devel] mpirun alternative

2021-03-05 Thread George Bosilca via devel
Gabriel, You should be able to. Here are at least 2 different ways of doing this. 1. Purely MPI. Start singletons (or smaller groups), and connect via sockets using MPI_Comm_join. You can setup your own DNS-like service, with the goal of having the independent MPI jobs leave a trace there, such t

Re: [OMPI devel] mpirun alternative

2021-03-05 Thread Ralph Castain via devel
I'm afraid that won't work - there is no way for the job to "self assemble". One could create a way to do it, but it would take some significant coding in the guts of OMPI to get there. On Mar 5, 2021, at 9:40 AM, Gabriel Tanase via devel mailto:devel@lists.open-mpi.org> > wrote: Hi all, I dec

[OMPI devel] mpirun alternative

2021-03-05 Thread Gabriel Tanase via devel
Hi all, I decided to use mpi as the messaging layer for a multihost database. However within my org I faced very strong opposition to allow passwordless ssh or rsh. For security reasons we want to minimize the opportunities to execute arbitrary codes on the db clusters. I don;t want to run other th