<br><br><div class="gmail_quote">On Tue, Aug 9, 2011 at 05:44, Manuel Jung <span dir="ltr">&lt;<a href="mailto:mjung@astrophysik.uni-kiel.de">mjung@astrophysik.uni-kiel.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br><br><div class="gmail_quote"><div class="im">2011/8/9 MinRK <span dir="ltr">&lt;<a href="mailto:benjaminrk@gmail.com" target="_blank">benjaminrk@gmail.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br><br><div class="gmail_quote"><div>On Mon, Aug 8, 2011 at 14:30, Manuel Jung <span dir="ltr">&lt;<a href="mailto:mjung@astrophysik.uni-kiel.de" target="_blank">mjung@astrophysik.uni-kiel.de</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

This is awesome! Thanks a lot! I gave your latest ipython git version a test and the registration with ssh tunneling for engines works. But i am not able to process any tasks. I get:<div><br></div><div>rc.ids==[0]</div><div>





rc[:].map_sync(lambda x: x**2, range(10))</div><div><br></div><div>... does not return! Also no load on the engine is registered. How can i debug this? There is no output on the ipcluster log.</div></blockquote><div><br>




</div></div><div>My fault, see below.</div><div><br></div><div>For debugging, I always recommend using ipcontroller/ipengine instead of ipcluster, and add the `--debug` flag to maximize logging output.  It&#39;s much easier to make sense of what&#39;s going on, even if it&#39;s not quite as convenient.</div>


<div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>Could you explain, why there are 6 instances of ipengine showing up in htop on my cluster node? (n==1)</div>




</blockquote><div><br></div></div><div>The tunnels are launched as subprocesses, so there should be 8 - 1 for each of seven(!) tunnels, plus one for the engine itself.  The fact that there are only 6 means two are missing, and it turns out that I managed to forget to forward the shell streams (the ones used for execution - pretty important).  I just rebased the branch on master with fixes, so if you check it out again it should hopefully be in working order.</div>




<div><br></div><font color="#888888"><div>-MinRK</div></font></div></blockquote><div> </div></div><div>Ok, now it works for n==1, or for n==4. But if i configure n==16 some engines fail to launch. This seems to be related to the error</div>


<div><br></div><div><div>[IPClusterStart] Warning: Identity file ~/.ssh/ip_dsa.pub not accessible: No such file or directory.</div></div><div><br></div><div>But why does this happen? Multiple reads shouldn&#39;t be a problem?</div>

</div></blockquote><div><br></div><div>128 simultaneous reads is a lot, so that could be hitting some limit.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="gmail_quote">
<div><br></div><div>I also tried without specifying an identity file, but using the system default one - still some ssh tunnels are failing.</div><div><br></div><div>Some suggestion: Would it be possible/easier to just build one ssh connection with all tunnels? </div>

</div></blockquote><div><br></div><div>I think this is possible, but I would have to rearrange some things.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="gmail_quote"><div>The process flood flood gets a little bit overwhelming with 16 cores, 16*8=128 processes.</div></div></blockquote><div><br></div><div>This is why manual tunnels make more sense for engines.  It&#39;s silly to set up a separate set of tunnels for each engine, when they are all pointing to the same place. </div>

<div><br></div><div>Even if I fold them all into one process, you are still forwarding 128 ports to the same 8 for no reason other than the engines don&#39;t know each other exist (and the engines must be allowed to shutdown in any order).  If you do the tunneling manually, and let the engines think they are local, then this will all be more efficient.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div><br></div><div>And maybe these could be made subprocesses of the ipengine call? Even if they timeout after 15 seconds this would be logical, wouldn&#39;t it?</div>

</div></blockquote><div><br></div><div>They are launched with pexpect, which I assumed would be subprocesses, but might not be.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="gmail_quote"><div><br></div><div>Cheers,</div><div>Manuel</div><div><font color="#888888">
</font><br></div><div>Ps.: I am attaching the ipcluster log. Maybe it helps.</div><div><div></div><div class="h5"><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div class="gmail_quote"><div><div><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><div>Also i get some failing tunnel setups for n&gt;1, but let us focus on n==1 for now.</div><div><div></div><div><div><br></div><div><br></div><div><br><br><div class="gmail_quote">2011/8/8 MinRK <span dir="ltr">&lt;<a href="mailto:benjaminrk@gmail.com" target="_blank">benjaminrk@gmail.com</a>&gt;</span><br>





<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As I mentioned, it was quite straightforward to add tunneling support, at least for the simplest case:<div><br></div><div>





<a href="https://github.com/ipython/ipython/pull/685" target="_blank">https://github.com/ipython/ipython/pull/685</a><br>

<br>:)</div><div><br><font color="#888888">-MinRK</font><div><div></div><div><br><br><div class="gmail_quote">On Sun, Aug 7, 2011 at 15:17, MinRK <span dir="ltr">&lt;<a href="mailto:benjaminrk@gmail.com" target="_blank">benjaminrk@gmail.com</a>&gt;</span> wrote:<br>





<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br><br><div class="gmail_quote"><div>On Sun, Aug 7, 2011 at 14:25, Manuel Jung <span dir="ltr">&lt;<a href="mailto:mjung@astrophysik.uni-kiel.de" target="_blank">mjung@astrophysik.uni-kiel.de</a>&gt;</span> wrote:<br>

</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
Well no answers yet, but i made some progression.<div><br></div><div>I was not able to work around the error, but i think i understand now, why this does not work.</div><div><br></div><div>The error appears, because the registration is successfull, but everything else like heartbeat etc. fails. For these operations were no ports forwarded.</div>









<div><br></div><div>It is stated here</div><div><br></div></div><div><a href="http://ipython.org/ipython-doc/stable/parallel/parallel_security.html#ssh" target="_blank">http://ipython.org/ipython-doc/stable/parallel/parallel_securitystandard.html#ssh</a></div>







<div>

<div><br></div><div>that tunneling for engines (which i tried) is not supported atm. I tried to work around this, but only created a tunnel for the registration socket - not for the other sockets, which are used by the engines. An overview of them is given here:</div>









<div><br></div><div><a href="http://ipython.org/ipython-doc/stable/development/parallel_connections.html#all-connections" target="_blank">http://ipython.org/ipython-doc/stable/development/parallel_connections.html#all-connections</a></div>









<div><br></div><div>Well i did specify the registration port, but i did not specify ports heartbeats etc. Am i able to do this to get homebrew engine tunneling? I saw a bunch of options which are maybe related in the configuration for the controller, but did&#39;nt quite understud, which ones i had to alter. </div>









<div><br></div><div>Maybe someone could point out, why there is no tunneling support for engines there (yet)? Is there any particular reason for this, other than just nobody did it yet?</div></div></blockquote><div><br></div>







<div>
Correct, some amount of ssh tunneling will be added to the engine, it just hasn&#39;t been done.  The reason it&#39;s a lower priority than the client-controller connections is just that it&#39;s more rare that engines can&#39;t see the controller directly.  It&#39;s also slightly less valuable, because engines are often run in environments that cannot accept input, so only passwordless ssh will work.  The client tunnels allow for input of a password (though I doubt that it works in every case).</div>








<div><br></div><div><br></div><div>As it stands now, there&#39;s no way to tell the engine to ignore the connection reply from the controller (which contains all of the non-registration connection info), so there are some restrictions on how you can trick the engine into connecting to different ports.  Essentially you will have to set up all 6 forwarded ports, and the Controller must be listening on localhost (can be in addition to localhost, e.g. 0.0.0.0 for all interfaces).</div>








<div><br></div><div>Prevent the JSON connector file from disambiguating localhost connections to the controller&#39;s external IP by specifying loopback, e.g.:</div><div><br></div><div>ipcontroller --ip=0.0.0.0 --location=127.0.0.1</div>








<div><br></div><div>That way, engines will always try to connect to localhost, regardless of where the Controller actually is running, enabling them to use your tunnels.</div><div><br></div><div>First, you must specify (or retrieve from the controller&#39;s debug output) all of the ports the controller is listening on for engine connections:</div>








<div><br></div><div>in ipcontroller_config.py:</div><div># port-pairs:</div><div>c.HubFactory.iopub</div><div>c.HubFactory.hb</div><div>c.HubFactory.task</div><div>c.HubFactory.mux</div><div>c.HubFactory.control</div><div>








<br></div><div>Then you can specify the tunnels manually (the local ports *must* be the same, for now). That will be the first port of each Queue (iopub, task, mux, control) and both hb ports, and the registration port.</div>








<div><br></div><div>So, I was able to get this running with the following commands:</div><div><br></div><div>1. start the controller, listening on all interfaces and forcing loopback IP for disambiguation:</div><div><br>







</div>
<div>[controller] $&gt; ipcontroller --ip=0.0.0.0 --location=127.0.0.1 --port=10101 --HubFactory.hb=10102,10112 --HubFactory.control=10203,10103 --HubFactory.mux=10204,10104 --HubFactory.task=10205,10105</div><div><br></div>








<div># (with this pattern, 101XY ports are ports visible to the engine, 102XY are client-only)</div><div><br></div><div>2. Set up forwarded ports on the engines.</div><div><br></div><div>[engine] $&gt; for port in 10101 10102 10112 10103 10104 10105; do ssh $server -f -N -L $port:$controller:$port; done</div>








<div><br></div><div>In my case, $server was a third machine that I have ssh access to that has access to $controller, where the controller process is running.  If you are tunneling directly, then $server would be the controller&#39;s IP, and $controller would be 127.0.0.1</div>








<div><br></div><div>3. connect the engine</div><div><br></div><div>[engine] $&gt;  ipengine --f=/path/to/ipcontroller-engine.json</div><div><br></div><div># note that if you are on a shared filesystem, just `ipengine` should work.</div>








<div><br></div><div>Implementing support for the easiest case should be quite straightforward, and less tedious than this. (Pull requests welcome!).</div><div><br></div><div>I hope that helps.</div><div><br></div><div>-MinRK</div>








<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>Thanks! </div>
<div>Manuel</div>
<br>_______________________________________________<br>
IPython-User mailing list<br>
<a href="mailto:IPython-User@scipy.org" target="_blank">IPython-User@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-user" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-user</a><br>
<br></blockquote></div><br>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div><br>
</blockquote></div></div></div><br>
</blockquote></div><br>