You are running into the fact that IPClusterStart is a subclass of IPClusterEngines.<div><br></div><div>Setting `IPClusterEngines.engine_launcher_class` will set the launcher for both `ipcluster engines` and `ipcluster start`, but setting `IPClusterStart.engine_launcher_class` will only set it for `ipcluster start`.</div>

<div><br></div><div>-MinRK</div><div><br><div class="gmail_quote">On Thu, Sep 8, 2011 at 15:37, eklavyaa <span dir="ltr">&lt;<a href="mailto:eklavyaa@gmail.com">eklavyaa@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>
This approach worked quite well, except for one caveat discussed below.<br>
<br>
<br>
To summarize, now the only change I have in ipcluster_config.py from the<br>
default is<br>
<div class="im">c.IPClusterStart.engine_launcher_class = &#39;LSFEngineSetLauncher&#39;<br>
</div>The ipcontroller_config.py edit remains the same:<br>
c.HubFactory.ip = &#39;*&#39;<br>
(I have called this profile lsf2)<br>
<br>
So the controller gets started locally on my dedicated node (which shares a<br>
common filesystem with the LSF nodes) and when the engines start on the LSF<br>
nodes, they can see the controller. I tested out an example and everything<br>
seems to be working well.<br>
<br>
<br>
<br>
However, if I try to do it by starting the engines separately using<br>
&quot;ipcluster engines&quot; or &quot;ipengine&quot;, things don&#39;t seem to work. Here&#39;s what I<br>
am doing.<br>
<br>
1. First start controller + engines using<br>
ipcluster start --n=2 --profile=lsf2<br>
<br>
(Note that the behavior below is the same even if I start the controller<br>
alone using  ipcontroller --profile=lsf2)<br>
<br>
This results in the controller starting locally and 2 engines starting on<br>
the LSF nodes.<br>
<br>
2. Now add more engines using<br>
ipcluster engines --profile=lsf2 --n=2<br>
<br>
--&gt; This results in the engines starting *locally* and not on the LSF Here&#39;s<br>
the log<br>
<br>
(vpython-272) username@machinename:~/.ipython$ ipcluster engines<br>
--profile=lsf2 --n=2<br>
[IPClusterEngines] Using existing profile dir:<br>
u&#39;/home/unix/username/.ipython/profile_lsf2&#39;<br>
[IPClusterEngines] IPython cluster: started<br>
[IPClusterEngines] Starting engines with [daemon=False]<br>
[IPClusterEngines] Starting 2 engines<br>
[IPClusterEngines] Process<br>
&#39;/home/unix/username/work/software/vpython-272/bin/python2.7&#39; started: 11997<br>
[IPClusterEngines] Starting LocalEngineSetLauncher:<br>
[&#39;/home/unix/username/work/software/vpython-272/bin/python2.7&#39;,<br>
u&#39;/home/unix/username/work/software/vpython-272/lib/python2.7/site-packages/IPython/parallel/apps/ipengineapp.py&#39;,<br>
&#39;--log-to-file&#39;, &#39;--log-level=20&#39;,<br>
u&#39;--profile-dir=/home/unix/username/.ipython/profile_lsf2&#39;]<br>
[IPClusterEngines] Process<br>
&#39;/home/unix/username/work/software/vpython-272/bin/python2.7&#39; started: 11998<br>
[IPClusterEngines] Process &#39;engine set&#39; started: [None, None]<br>
[IPClusterEngines] [IPEngineApp] Using existing profile dir:<br>
u&#39;/home/unix/username/.ipython/profile_lsf2&#39;<br>
[IPClusterEngines] [IPEngineApp] Using existing profile dir:<br>
u&#39;/home/unix/username/.ipython/profile_lsf2&#39;<br>
<br>
2. Trying adding more engines using --engines=LSFEngineSetLauncher<br>
--&gt; This submits jobs to LSF but times out, I guess because I have not<br>
specified the profile. However, adding --profile=lsf2 doesn&#39;t help either.<br>
<br>
(vpython-272)username@machinename:~$ ipcluster engines<br>
--engines=LSFEngineSetLauncher --n=2<br>
<br>
[IPClusterEngines] Using existing profile dir:<br>
u&#39;/home/unix/username/.ipython/profile_default&#39;<br>
[IPClusterEngines] IPython cluster: started<br>
[IPClusterEngines] Starting engines with [daemon=False]<br>
[IPClusterEngines] Starting 2 engines<br>
[IPClusterEngines] Starting 2 engines with LSFEngineSetLauncher: [&#39;bsub&#39;,<br>
u&#39;./lsf_engines&#39;]<br>
[IPClusterEngines] adding job array settings to batch script<br>
[IPClusterEngines] Writing instantiated batch script: ./lsf_engines<br>
[IPClusterEngines] Job submitted with job id: &#39;8833039&#39;<br>
[IPClusterEngines] Process &#39;bsub&#39; started: &#39;8833039&#39;<br>
<br>
<br>
Please let me know how I can add engines, using an the existing profile<br>
(such as lsf2 above).<br>
<br>
Thanks!<br>
<br>
-E<br>
<div class="im"><br>
<br>
<br>
<br>
<br>
<br>
<br>
On Thu, Sep 8, 2011 at 13:37, eklavyaa &lt;<a href="mailto:eklavyaa@gmail.com">eklavyaa@gmail.com</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt; Based on MinRK&#39;s suggestion, I tried increasing the timeout for engine<br>
&gt; registration by increasing<br>
&gt; c.EngineFactory.timeout and this seems to be a temporary fix to the<br>
&gt; problem.<br>
&gt;<br>
&gt; However, the issue here is that there is no guarantee that the controller<br>
&gt; node will get allocated first (even if that job is submitted first),<br>
&gt; especially if I request for a large number of nodes. This is true in most<br>
&gt; case for LSF / SGE / PBS. Further, it is typically the case the controller<br>
&gt; would need to run much longer than engines (since not all engines get<br>
&gt; allocated right away), and getting long jobs on LSF is difficult.<br>
&gt;<br>
<br>
<br>
</div><div><div></div><div class="h5">&gt; I have a dedicated node on which I can locally start a controller. This<br>
&gt; node<br>
&gt; has a common filesystem with the LSF nodes, on which I intend to start the<br>
&gt; engines. I am guaranteed that the controller process will start instantly<br>
&gt; since its a dedicated node, so if I set c.EngineFactory.timeout=10, I can<br>
&gt; be<br>
&gt; almost certain that the timeout issue will not take place.<br>
&gt;<br>
&gt; Does this make sense? If so, please let me know (or please guide me to the<br>
&gt; documentation) as to how I can setup a controller locally, and engines on<br>
&gt; LSF nodes.<br>
&gt;<br>
<br>
Yes, this makes perfect sense, and is in fact how I run most often.  This is<br>
precisely why the Controller and Engine launchers are separate.  There is no<br>
need for the ControllerLauncher to match that of the engines, and the<br>
default (Local) launcher is often just fine with any/all of the engine<br>
launchers.  If you are starting the controller on a node on the same cluster<br>
(or at least same filesystem and accessible on the network), then simply<br>
leaving the ControllerLauncher as the default local launcher should be the<br>
only change necessary.<br>
<br>
Extra note:<br>
<br>
In fact, there is not even any need to start the controller with ipcluster.<br>
 All `ipcluster start` does is run `ipcontroller` once, and `ipengine` n<br>
times.  The various launchers simply wrap these one-line calls in extremely<br>
basic batch-files with knowledge of how to start/stop jobs.  If you want to<br>
run ipcontroller manually (especially useful for debug output), then you can<br>
skip the controller-launching step of ipcluster with `ipcluster engines`,<br>
which is identical to `ipcluster start`, only omitting the startup of a<br>
controller.  This allows you to run LSF engines on a cluster, with a<br>
controller that is arbitrarily elsewhere on the internet.<br>
<br>
-MinRK<br>
<br>
<br>
</div></div><font color="#888888">--<br>
View this message in context: <a href="http://old.nabble.com/IPython-LSF-support-tp32375842p32427637.html" target="_blank">http://old.nabble.com/IPython-LSF-support-tp32375842p32427637.html</a><br>
</font><div><div></div><div class="h5">Sent from the IPython - User mailing list archive at Nabble.com.<br>
<br>
_______________________________________________<br>
IPython-User mailing list<br>
<a href="mailto:IPython-User@scipy.org">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>
</div></div></blockquote></div><br></div>