<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    hi there, sorry for entering late into the discussion, I am the
    author for the little code that was necessary to run LSF. I am very
    happy to see that with suggestions from Min indeed someone else
    managed to make good use of it.<br>
    Indeed, in my mind it is quite natural to have the controller on a
    dedicated node, as for now I only experienced issues sending it to
    the batch as well. <br>
    <br>
    I will follow the traffic more closely in case you have other
    questions, but I know much less than Min on the system, and the LSF
    code added was really quite trivial to implement, given the
    fantastic work on ipython upstream.<br>
    <br>
    best,<br>
    Johann<br>
    <br>
    On 09/08/2011 11:06 PM, MinRK wrote:
    <blockquote
cite="mid:CAHNn8BVbnmbOqnjzusJf-vvSwrtxVV79YBmo_1t+5j44j8D+oQ@mail.gmail.com"
      type="cite"><br>
      <br>
      <div class="gmail_quote">On Thu, Sep 8, 2011 at 13:37, eklavyaa <span
          dir="ltr">&lt;<a moz-do-not-send="true"
            href="mailto:eklavyaa@gmail.com">eklavyaa@gmail.com</a>&gt;</span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          padding-left: 1ex;">
          <br>
          Based on MinRK's suggestion, I tried increasing the timeout
          for engine<br>
          registration by increasing<br>
          c.EngineFactory.timeout and this seems to be a temporary fix
          to the problem.<br>
          <br>
          However, the issue here is that there is no guarantee that the
          controller<br>
          node will get allocated first (even if that job is submitted
          first),<br>
          especially if I request for a large number of nodes. This is
          true in most<br>
          case for LSF / SGE / PBS. Further, it is typically the case
          the controller<br>
          would need to run much longer than engines (since not all
          engines get<br>
          allocated right away), and getting long jobs on LSF is
          difficult.<br>
        </blockquote>
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          padding-left: 1ex;"><br>
          <br>
          I am thinking of working around this problem using the
          following approach.<br>
          Please let me know whether this makes sense.<br>
          <br>
          I have a dedicated node on which I can locally start a
          controller. This node<br>
          has a common filesystem with the LSF nodes, on which I intend
          to start the<br>
          engines. I am guaranteed that the controller process will
          start instantly<br>
          since its a dedicated node, so if I set
          c.EngineFactory.timeout=10, I can be<br>
          almost certain that the timeout issue will not take place.<br>
          <br>
          Does this make sense? If so, please let me know (or please
          guide me to the<br>
          documentation) as to how I can setup a controller locally, and
          engines on<br>
          LSF nodes.<br>
        </blockquote>
        <div><br>
        </div>
        <div>Yes, this makes perfect sense, and is in fact how I run
          most often.  This is precisely why the Controller and Engine
          launchers are separate.  There is no need for the
          ControllerLauncher to match that of the engines, and the
          default (Local) launcher is often just fine with any/all of
          the engine launchers.  If you are starting the controller on a
          node on the same cluster (or at least same filesystem and
          accessible on the network), then simply leaving the
          ControllerLauncher as the default local launcher should be the
          only change necessary.</div>
        <div>
          <div><br>
          </div>
        </div>
        <div>Extra note:</div>
        <div><br>
        </div>
        <div>In fact, there is not even any need to start the controller
          with ipcluster.  All `ipcluster start` does is run
          `ipcontroller` once, and `ipengine` n times.  The various
          launchers simply wrap these one-line calls in extremely basic
          batch-files with knowledge of how to start/stop jobs.  If you
          want to run ipcontroller manually (especially useful for debug
          output), then you can skip the controller-launching step of
          ipcluster with `ipcluster engines`, which is identical to
          `ipcluster start`, only omitting the startup of a controller.
           This allows you to run LSF engines on a cluster, with a
          controller that is arbitrarily elsewhere on the internet.</div>
        <div><br>
        </div>
        <div>-MinRK</div>
        <div> </div>
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          padding-left: 1ex;">
          <br>
          <br>
          -E<br>
          <div>
            <div class="h5"><br>
              <br>
              <br>
              [resending since message was apparently not accepted the
              first time.]<br>
              <br>
              It seems to work with the following edits to the
              configuration<br>
              <br>
              The config files were created using<br>
              ipython profile create --parallel --profile=lsf<br>
              <br>
              ipcluster_config.py edits:<br>
              c.IPClusterStart.controller_launcher_class =
              'LSFControllerLauncher'<br>
              c.IPClusterStart.engine_launcher_class =
              'LSFEngineSetLauncher'<br>
              <br>
              ipcontroller_config.py edits:<br>
              c.HubFactory.ip = '*'<br>
              <br>
              <br>
              I was able to start the controller and engine using<br>
              ipcluster start --n=2 --profile=lsf<br>
              <br>
              However, the engines would occasionally time-out. Here are
              the logs of two<br>
              engines from the same session<br>
              <br>
              $ cat ipengine.e.8694278<br>
              [IPEngineApp] Using existing profile dir:<br>
              u'/home/unix/username/.ipython/profile_lsf'<br>
              [IPEngineApp] Loading url_file<br>
u'/home/unix/shsingh/.ipython/profile_lsf/security/ipcontroller-engine.json'<br>
              [IPEngineApp] Registering with controller at
              tcp://X.X.X.X:36875<br>
              [IPEngineApp] Completed registration with id 0<br>
              [IPEngineApp] Engine Interrupted, shutting down...<br>
              <br>
              <br>
              $ cat ipengine.e.8694300<br>
              [IPEngineApp] Using existing profile dir:<br>
              u'/home/unix/username/.ipython/profile_lsf'<br>
              [IPEngineApp] Loading url_file<br>
u'/home/unix/shsingh/.ipython/profile_lsf/security/ipcontroller-engine.json'<br>
              [IPEngineApp] Registering with controller at
              tcp://X.X.X.X:36875<br>
              [IPEngineApp] Registration timed out after 2.0 seconds<br>
              <br>
              The first one was able to register, while the second one
              was not and would<br>
              thus time-out.<br>
              <br>
              My guess is that it is something to do with the fact that
              the engines might<br>
              be getting allocated to a node before the controller, but
              can't verify this.<br>
              <br>
              Note that this time-out issue happens most, but not all,
              the time.<br>
              <br>
              Any ideas on what might be going wrong?<br>
              <br>
              -E<br>
              <br>
              <br>
              <br>
            </div>
          </div>
          <div class="im">Yes, 0.11 has LSF support.  Just use the<br>
            LSFEngineSetLauncher/LSFControllerLauncher,<br>
            the same as you would with PBS or SGE.<br>
            <br>
            It is basically untested, as the author of the LSF launchers
            is the only one<br>
            to have tested it, to our knowledge, so please let us know
            about<br>
            shortcomings, etc..  I should scan through the docs to make
            sure they aren't<br>
            out of sync.<br>
            <br>
            -MinRK<br>
            <br>
            <br>
            <br>
            <br>
          </div>
          <font color="#888888">--<br>
            View this message in context: <a moz-do-not-send="true"
href="http://old.nabble.com/IPython-LSF-support-tp32375842p32426952.html"
              target="_blank">http://old.nabble.com/IPython-LSF-support-tp32375842p32426952.html</a><br>
          </font>
          <div>
            <div class="h5">Sent from the IPython - User mailing list
              archive at Nabble.com.<br>
              <br>
              _______________________________________________<br>
              IPython-User mailing list<br>
              <a moz-do-not-send="true"
                href="mailto:IPython-User@scipy.org">IPython-User@scipy.org</a><br>
              <a moz-do-not-send="true"
                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>
      <br>
      -- <br>
      This message has been scanned for viruses and
      <br>
      dangerous content by
      <a moz-do-not-send="true" href="http://www.mailscanner.info/"><b>MailScanner</b></a>,
      and is
      <br>
      believed to be clean.
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
IPython-User mailing list
<a class="moz-txt-link-abbreviated" href="mailto:IPython-User@scipy.org">IPython-User@scipy.org</a>
<a class="moz-txt-link-freetext" href="http://mail.scipy.org/mailman/listinfo/ipython-user">http://mail.scipy.org/mailman/listinfo/ipython-user</a>
</pre>
    </blockquote>
  </body>
</html>