Install and use the openlava job scheduler and openlava web GUI on CentOS

Scheduling on Linux mostly happens with cron or any of it’s variations. Although cron is very powerful, it lacks a few features to use it in a flexible way and especially when you want to create dependencies or “communicate” with jobs running on other hosts, it has it’s shortcomings. Cron wasn’t really designed with those features in mind. Fortunately there are a few nice schedulers out there which can be used to overcome those limitations. A few of them are SOS Jobscheduler, GNUBatch and openlava. Openlava is a limited open source fork of LSF which is now owned by IBM. Openlava doesn’t come with a GUI but there is another project, Openlava web which enables control over openlava via a web interface.

Openlava is a limited fork of an old version of platform LSF, which allows job scheduling on multiple nodes. The scheduler is designed to work in large clusters but can be used to schedule jobs on a few nodes as well. Managing openlava is limited to the CLI but to get an overview of the running and planned jobs in openlava, I will also install Openlava web which is created by David Irvine. Openlava itself has a clear documentation, the webgui part isn’t that good documented, especially if you don’t have a lot of experience with Django and Python packaging.

More information about openlava: http://www.openlava.org/
More information about openlava web: https://www.clusterfsck.io/static/openlava-web/index.html

In this post, I’ll install openlava on two nodes (node01 and node02). Node01 will be used as the master.

The firs thing we’ll do is install openlava on two nodes and get them to communicate and schedule jobs. As with many of my posts, I used CentOS 7 to put this together. Once we get the scheduler to work, I’ll add the web interface on top of it.

Prepare the system

Before we start, we need to make sure that both nodes know their own hostname and can communicate with each other using that name:

In case this doesn’t work or you get a message saying: hostname: Name or service not known, change /etc/hosts to include the hostname of this node and the other node. If the machine can’t resolve it’s own fqdn, you might get messages in syslog similar to this when starting openlava

Set up system mail

Although this step is optional, it’s highly recommended. By default, openlava is sending a mail when a job finishes in the schedule. This mail contains more information about the job and the job’s output. In order for this to function correctly, we need to configure our hosts to allow them to send mails.

Sending mail can be done in a lot of ways. The most popular packages for this are Sendmail or Postfix. This time, I’ll configure Postfix. I’ll only put the actions and output here for node01 but you need to apply the exact same configuration on node02.

Let’s start with installing the Postfix package:

If you want to, you can set your SMTP-server as relayhost in /etc/postfix/main.cf but I’ll let each host be it’s own relay so I don’t need to touch any of the configuration files of Postfix.

To let mails be send to my own e-mail when sent to my userid, I need to associate my own address to the Linux user. This can be done in /etc/aliases:

After editing the file, you need to reload the contents of the aliases:

Al that’s left to do is to start Postfix:

In case you experience problems with mail, you can check the contents of /var/log/maillog.

Allow communication trough the firewall

The last step of the preparation is to open the necessary ports in the firewall to allow communication between both nodes. Although there are four fixed port numbers in the configuration file /opt/openlava-2.2/etc/lsf.conf, I noticed that openlava also uses dynamic ports to communicate and they’re somewhere between 1024 and 65535… Unfortunately, I couldn’t find any clear information about this in the documentation and on the mailinglist, people only suggest to stop iptables. So the best I could do is to allow the range of ports through the firewall.

Install openlava

Now that we’re sure that the hosts know their name, can talk with each other and send mail to myself, it’s time to install openlava. Openlava is available in an RPM package so we can download install openlava directly with Yum on both nodes:

Once we installed openlava on both nodes, we need to make the nodes aware of each other by editing the file /opt/openlava-2.2/etc/lsf.cluster.openlava:

This file needs to be present on both nodes with the same content.

During RPM installation, openlava was automatically started so in order to let the changed configuration become active, we need to restart it. Openlava still used init scripts while,  since CentOS 7, systemd is used. For now this isn’t really a problem but it would be more clean to create a systemd service file openlava too (maybe later). The init script is using the killall command which isn’t part of CentOS anymore by default.

Let’s first install killall, which is part of the psmisc package:

And then we’ll restart openlava:

The RPM package also created a file in /etc/profile.d/openlava.sh which sets a few environment variables in order for openlava to function properly. To load those variables, we need to login again, su to the same user or simply source the script once manually. For all next times you log in to the machine, the script should be loaded automatically.

Now, the directory, which contains the openlava binaries, is added to $PATH and we can check out the status of our cluster nodes:

As you can see in the above output, node02 has node01 as it’s master because of the order in the configuration file.

To see if both nodes can communicate and see each other:

Everything seems to be running fine so let’s submit our first job on both nodes. You can submit jobs using the bsub command. The command takes a lot of arguments since it defines all conditions and options that have to do with the job. The complete syntax can be found here.

To submit and check a job on the first node:

In the output we can see that the job was added to the queue called normal and ended up in the status PEND (pending). Shortly after that, the status changed to RUN (running) and after the job completed it got status DONE.

As soon as the job finishes, we received a mail containing the following:

The mail contains the job output, saying the result of hostname and whoami.

Let’s try the same on node02 from the master node (node01):

The mail contains very similar output like our first job, only the output was different since the result of hostname was different to show that it actually ran on the second node.

Submit jobs with dependencies

Some other useful example of the bsub command:

Submit a job that will be executed at 20:30 and give it a name first_job:

Submit a job that will only start after first_job is finished:

To get more information about pending jobs and the exact reason that they’re pending:

Install Openlava web

Now that our scheduler is up and running and we know how to submit and control jobs, it could be nice to get a good overview with a GUI. A web interface was made for openlava called Openlava web so let’s get this up and running on the master.

The first step is to install all dependencies for the web interface:

Next we’ll install the necessary Python modules using pip:

First we need to get openlava-python ready on our system so let’s clone the git repository in /opt:

The setup.py script will look for certain files related to openlava but does that by default in the wrong paths. We need to adjust setup.py in order to look for the correct files:

Adjust the lsfdir variable to search in /opt/openlava-2.2, the path that was used during the RPM-installation.

After correcting the path, we can compile and install openlava-ptyhon:

Next is the webgui itself.

First clone the git repo and the submodules:

After cloning the repository and it’s requirements, let’s install openlava-web:

Now that we have all requirements to start, let’s create a new Django project in the /opt directory and copy the openlava directory in the project:

Now that all necessary files are in place, we need to enable the openlava webui in the Django project:

Edit /opt/openlava_webui/openlava_webui/urls.py and the openlavaweb.urls:

Edit /opt/openlava_webui/openlava_webui/settings.py to include openlavaweb:

At this point, the web interface should be installed but before we can test it, we need to open up port 80 in our firewall:

Now, let’s start a small webserver with our Django project to test the webinterface:

You can now connect with your browser to the ip or hostname of node01:

openlava_ui1

This interface already allows you to list all information from the scheduler and see running and pending jobs but logging in and changing anything won’t work yet. We need to talk with openlave as root and that can’t be done using the Django WSGI.

Enable control via the webinterface

In order to control openlava with the webinterface, we need to use FastCGI and that can be started as root. To connect to the FastCGI-server, we need to place a webserver in front of it which redirects our requests to the FastCGI from our Django project. To do this, we will use Lighttpd.

Lighttpd was already installed in the very first step of this post so the only thing that’s left is to configure it and start it.

Edit /etc/lighttpd/modules.conf and enable the alias and fastcgi modules:

Edit /etc/lighttpd/lighttpd.conf and add the following to the end of the file:

Start Lighttpd:

To enable login at the web interface we need to create a user that can do so:

Now our lighttpd server is started but we told it to forward requests to 127.0.0.1 on port 3033 for FastCGI so we need to start the Django project on that port:

Now connect to the ip or hostname of node1 and go to http://node01/olweb to get to the web interface for openlave using Lighttpd.

In the top right corner, click login and enter the username and password which you entered with the syncdb step above:

openlava_ui2

To list and manage jobs, you can use the jobs section as you could do in the read-only version:

openlava_ui_4

Now we can click on a job ID to edit the job and kill it for example:

openlava_ui_5

After logging in, there is also a new entry in the menu: Submit which allows you to submit new jobs, as we did with the bsub command:

openlava_ui3

After submitting, you get a summary:

openlava_ui_6

And we can see that the job has started:

openlava_ui_7

This is basically all that it takes to install openlava and configure it with a web interface. The web interface can probably installed in a better way but this is how I got it working since my knowledge of Django is very limited. For everything to work after a reboot, you need to enable the lighttpd service and create a service entry for the FastCGI of the Django project.

28 thoughts on “Install and use the openlava job scheduler and openlava web GUI on CentOS

  1. Excellent write up, rather than editing setup.py you can also run LSF_ENVDIR=/path/to/openlava python setup.py install if openlava is not installed in /opt/openlava, I will update setup.py to look in the default rpm location too.

  2. Great guide!
    I followed the instruction and successfully installed openlava web portal on CentOS 7. To enable yum to find required packages, I also installed Fedora EPEL:
    # yum install epel-release

  3. sudo python /opt/openlava_webui/manage.py runserver 0.0.0.0:80

    but there is no manage.py there, actually there is nothing but a folder there named openlavaweb created one step before: sudo cp -r /opt/openlava-web/openlavaweb/ /opt/openlava_webui/

    Do you know what could be the issue that i don’t have manage.py nowhere under /opt and i even checked the http git repository for it (https://github.com/irvined1982/openlava-web) with the same nowhere-to-be-found result

    • As far as I know, the command before the copy: “sudo django-admin startproject openlava_webui” should create the manage.py.

  4. When I try to install openlava-python, it fails spectacularly. Did something change? It would seem that the syntax has changed in gcc or something.
    Using Centos 7 kernel 3.10.0-229.4.2.el7.x86_64
    gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC)
    Openlava 3.0

    Errors from “python setup.py install”:

    /opt/openlava-3.0/include/lsf.h:19:0: warning: “_GNU_SOURCE” redefined [enabled by default]
    #define _GNU_SOURCE
    ^
    In file included from /usr/include/python2.7/pyconfig.h:6:0,
    from openlava/lsblib.c:8:
    /usr/include/python2.7/pyconfig-64.h:1160:0: note: this is the location of the previous definition
    #define _GNU_SOURCE 1
    ^
    openlava/lsblib.c: In function ‘__pyx_pf_8openlava_6lsblib_9JobMsgLog_5usrId___get__’:
    openlava/lsblib.c:45603:55: error: ‘struct jobMsgLog’ has no member named ‘usrId’
    __pyx_t_1 = __Pyx_PyInt_From_int(__pyx_v_self->_data->usrId); if (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 4512; __pyx_clineno = __LINE__; goto __pyx_L1_error;}
    ^
    openlava/lsblib.c: In function ‘__pyx_pf_8openlava_6lsblib_9JobMsgLog_5msgId___get__’:
    openlava/lsblib.c:45729:55: error: ‘struct jobMsgLog’ has no member named ‘msgId’
    __pyx_t_1 = __Pyx_PyInt_From_int(__pyx_v_self->_data->msgId); if (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 4522; __pyx_clineno = __LINE__; goto __pyx_L1_error;}
    ^
    openlava/lsblib.c: In function ‘__pyx_pf_8openlava_6lsblib_9JobMsgLog_4type___get__’:
    openlava/lsblib.c:45792:55: error: ‘struct jobMsgLog’ has no member named ‘type’
    __pyx_t_1 = __Pyx_PyInt_From_int(__pyx_v_self->_data->type); if (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 4527; __pyx_clineno = __LINE__; goto __pyx_L1_error;}
    ^
    openlava/lsblib.c: In function ‘__pyx_pf_8openlava_6lsblib_9JobMsgLog_3src___get__’:
    openlava/lsblib.c:45856:59: error: ‘struct jobMsgLog’ has no member named ‘src’
    __pyx_t_1 = __Pyx_PyBytes_FromString(__pyx_v_self->_data->src); if (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 4532; __pyx_clineno = __LINE__; goto __pyx_L1_error;}
    ^
    openlava/lsblib.c: In function ‘__pyx_pf_8openlava_6lsblib_9JobMsgLog_4dest___get__’:
    openlava/lsblib.c:45924:59: error: ‘struct jobMsgLog’ has no member named ‘dest’
    __pyx_t_1 = __Pyx_PyBytes_FromString(__pyx_v_self->_data->dest); if (unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 4537; __pyx_clineno = __LINE__; goto __pyx_L1_error;}
    ^
    error: command ‘gcc’ failed with exit status 1

    • edit file: /opt/openlava-3.0/include/lsbatch.h

      change:
      struct jobMsgLog {
      int jobId;
      int idx;
      char *msg;
      int usrId;
      int msgId;
      int type;
      char *src;
      char *dest;
      };

      It should compile

  5. If you add “myorigin = $mydomain” to the top of main.cf you will not need to add any aliases. If the node is a send only postfix host then I recommend the following added to the top of the file.
    ###
    myorigin = $mydomain
    inet_interfaces = loopback-only
    mydestination =
    ###

  6. Thanks for this nice tutorial!
    I encountered the following problem. As soon as I connect to the server with my browser I get the following error message:
    ImportError at /
    liblsf.so.0: cannot open shared object file: No such file or directory
    in
    /opt/openlava_webui/openlavaweb/cluster/openlavacluster.py in , line 22

    I think this results from a not defined env variable, but I’m really not sure (I defined LD_LIBRARY_PATH as /opt/openlava-3.0/lib …where the not imported file is located)

    Greets,
    Markus

    • Update: I was right with the LD_LIBRARY-PATh environmental variable. Although I defined it the linker couldn’t find it. So i defined it in /etc/ld.so.conf –> updated ldconfig and repeated the procedure…now it is working!!!

  7. Running into some trouble with the openlava-python build. The setup.py seems to run, but afterwards I can’t seem to import lsblib from openlava. I should have all the dependencies installed and the only difference between my version of openlava and the one in this guide is that I’m using openlava 3.0. Build details below:

    System:
    CentOS 7 3.10.0-229.11.1.el7.x86_64
    gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC)

    running install
    running build
    running build_py
    creating build
    creating build/lib.linux-x86_64-2.7
    creating build/lib.linux-x86_64-2.7/openlava
    copying openlava/__init__.py -> build/lib.linux-x86_64-2.7/openlava
    running build_ext
    cythoning openlava/lsblib.pyx to openlava/lsblib.c
    warning: openlava/openlava_base.pxd:23:16: Function signature does not match previous declaration
    building ‘openlava.lsblib’ extension
    creating build/temp.linux-x86_64-2.7
    creating build/temp.linux-x86_64-2.7/openlava
    gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong –param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong –param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/opt/openlava-3.0/etc/../include -I. -I/usr/include/python2.7 -c openlava/lsblib.c -o build/temp.linux-x86_64-2.7/openlava/lsblib.o -O3 -Wall
    In file included from /opt/openlava-3.0/etc/../include/lsbatch.h:26:0,
    from openlava/lsblib.c:242:
    /opt/openlava-3.0/etc/../include/lsf.h:19:0: warning: “_GNU_SOURCE” redefined [enabled by default]
    #define _GNU_SOURCE
    ^
    In file included from /usr/include/python2.7/pyconfig.h:6:0,
    from /usr/include/python2.7/Python.h:8,
    from openlava/lsblib.c:4:
    /usr/include/python2.7/pyconfig-64.h:1160:0: note: this is the location of the previous definition
    #define _GNU_SOURCE 1
    ^
    gcc -pthread -shared -Wl,-z,relro build/temp.linux-x86_64-2.7/openlava/lsblib.o /opt/openlava-3.0/etc/../lib/liblsf.a /opt/openlava-3.0/etc/../lib/liblsbatch.a -L/opt/openlava-3.0/etc/../lib -L. -llsf -llsbatch -lnsl -lpython2.7 -o build/lib.linux-x86_64-2.7/openlava/lsblib.so -g
    cythoning openlava/lslib.pyx to openlava/lslib.c
    warning: openlava/openlava_base.pxd:23:16: Function signature does not match previous declaration
    building ‘openlava.lslib’ extension
    gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong –param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong –param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/opt/openlava-3.0/etc/../include -I. -I/usr/include/python2.7 -c openlava/lslib.c -o build/temp.linux-x86_64-2.7/openlava/lslib.o -O3 -Wall
    In file included from /opt/openlava-3.0/etc/../include/lsbatch.h:26:0,
    from openlava/lslib.c:243:
    /opt/openlava-3.0/etc/../include/lsf.h:19:0: warning: “_GNU_SOURCE” redefined [enabled by default]
    #define _GNU_SOURCE
    ^
    In file included from /usr/include/python2.7/pyconfig.h:6:0,
    from /usr/include/python2.7/Python.h:8,
    from openlava/lslib.c:4:
    /usr/include/python2.7/pyconfig-64.h:1160:0: note: this is the location of the previous definition
    #define _GNU_SOURCE 1
    ^
    gcc -pthread -shared -Wl,-z,relro build/temp.linux-x86_64-2.7/openlava/lslib.o /opt/openlava-3.0/etc/../lib/liblsf.a /opt/openlava-3.0/etc/../lib/liblsbatch.a -L/opt/openlava-3.0/etc/../lib -L. -llsf -llsbatch -lnsl -lpython2.7 -o build/lib.linux-x86_64-2.7/openlava/lslib.so -g
    running install_lib
    copying build/lib.linux-x86_64-2.7/openlava/lsblib.so -> /usr/lib64/python2.7/site-packages/openlava
    copying build/lib.linux-x86_64-2.7/openlava/lslib.so -> /usr/lib64/python2.7/site-packages/openlava
    running install_egg_info
    Removing /usr/lib64/python2.7/site-packages/openlava_bindings-1.0-py2.7.egg-info
    Writing /usr/lib64/python2.7/site-packages/openlava_bindings-1.0-py2.7.egg-info
    Traceback (most recent call last):
    File “./test.py”, line 20, in
    from openlava import lsblib
    ImportError: liblsf.so.0: cannot open shared object file: No such file or directory
    TESTS FAILED

  8. HI .. Wanted to try OpenLAVA as our HPC clustering solution.

    I am looking kind of software where i can build my Master .. install cluster software (OpenLAVA) and master to my new brand node machine which can be pushed thru the network boot on node machines.

    How can i do this thru using OpenLAVA. Please suggest.

    Regards,
    Srikanth.K
    +91-9986236963.

  9. Attempting to install with openlava 3.0 on CentOS 6.7

    Getting all the way to testing the web page and I get:

    ClusterException at /
    Unable to get list of queues: Failed in an LSF library call
    Request Method: GET
    Request URL: http://openlava.luxtera.com/
    Django Version: 1.4.21
    Exception Type: ClusterException
    Exception Value:
    Unable to get list of queues: Failed in an LSF library call
    Exception Location: /opt/openlava_webui/openlavaweb/cluster/openlavacluster.py in raise_cluster_exception, line 262
    Python Executable: /usr/bin/python
    Python Version: 2.6.6
    Python Path:
    [‘/opt/openlava_webui’,
    ‘/usr/lib/python2.6/site-packages/django_openlavaweb-1.1-py2.6.egg’,
    ‘/usr/lib64/python26.zip’,
    ‘/usr/lib64/python2.6’,
    ‘/usr/lib64/python2.6/plat-linux2’,
    ‘/usr/lib64/python2.6/lib-tk’,
    ‘/usr/lib64/python2.6/lib-old’,
    ‘/usr/lib64/python2.6/lib-dynload’,
    ‘/usr/lib64/python2.6/site-packages’,
    ‘/usr/lib/python2.6/site-packages’,
    ‘/usr/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg-info’]
    Server time: Thu, 10 Sep 2015 17:27:59 -0500

    I’ve already resolved the “/opt/openlava-3.0/include/lsbatch.h” issue and the “liblsf.so.0: cannot open shared object file: No such file or directory” issue.

  10. Reloaded from scratch with CentOS 7. Same exact error message on web page. Unable to get list of queues.

    Ran into the “/opt/openlava-3.0/include/lsbatch.h” issue and the “liblsf.so.0: cannot open shared object file: No such file or directory” issues as well during the install.

    • Hi,

      Probably there have been some changes in the packages. I haven’t got a lot of time recently to spend time on this. I would need to look into it a little better to give you some useful information.

  11. I am having the exact same issues as Bob on a fresh minimal CentOS7 install. I also had the “/opt/openlava-3.0/include/lsbatch.h” issue and the “liblsf.so.0: cannot open shared object file: No such file or directory” issues and corrected them.
    Now I get the following error message

    Any assistance would be greatly appreciated

    ClusterException at /
    Unable to get list of queues: Failed in an LSF library call
    Request Method: GET
    Request URL: http://192.168.30.149/
    Django Version: 1.6.11
    Exception Type: ClusterException
    Exception Value:
    Unable to get list of queues: Failed in an LSF library call
    Exception Location: /opt/openlava_webui/openlavaweb/cluster/openlavacluster.py in raise_cluster_exception, line 262
    Python Executable: /usr/bin/python
    Python Version: 2.7.5
    Python Path:
    [‘/opt/openlava_webui’,
    ‘/usr/lib/python2.7/site-packages/django_openlavaweb-1.1-py2.7.egg’,
    ‘/usr/lib64/python27.zip’,
    ‘/usr/lib64/python2.7’,
    ‘/usr/lib64/python2.7/plat-linux2’,
    ‘/usr/lib64/python2.7/lib-tk’,
    ‘/usr/lib64/python2.7/lib-old’,
    ‘/usr/lib64/python2.7/lib-dynload’,
    ‘/usr/lib64/python2.7/site-packages’,
    ‘/usr/lib/python2.7/site-packages’]
    Server time: Thu, 5 Nov 2015 00:17:52 +0000

  12. Just an additional note, I just built a clean CentOS 6 box and tried it on that, same error. So both CentOS 6 & 7 are affected.
    Also noticed this while going through the process when issuing the command
    django-admin startproject openlava_webui
    you have the same name twice and it complains about it already existed, perhaps this is causing some issues?

    Here is the output when access the url
    Thanks

    Request Method: GET
    Request URL: http://192.168.30.154/
    Django Version: 1.4.21
    Exception Type: ClusterException
    Exception Value:
    Unable to get list of queues: Failed in an LSF library call
    Exception Location: /opt/openlava_webui/openlavaweb/cluster/openlavacluster.py in raise_cluster_exception, line 262
    Python Executable: /usr/bin/python
    Python Version: 2.6.6
    Python Path:
    [‘/opt/openlava_webui’,
    ‘/usr/lib/python2.6/site-packages/django_openlavaweb-1.1-py2.6.egg’,
    ‘/usr/lib64/python26.zip’,
    ‘/usr/lib64/python2.6’,
    ‘/usr/lib64/python2.6/plat-linux2’,
    ‘/usr/lib64/python2.6/lib-tk’,
    ‘/usr/lib64/python2.6/lib-old’,
    ‘/usr/lib64/python2.6/lib-dynload’,
    ‘/usr/lib64/python2.6/site-packages’,
    ‘/usr/lib/python2.6/site-packages’,
    ‘/usr/lib/python2.6/site-packages/setuptools-0.6c11-py2.6.egg-info’]

    • Hello, James

      Could you please explain how you resolved “liblsf.so.0: cannot open shared object file: No such file or directory” issue?

      Thank you in advance

    • Hello again
      Looks like I resolved the issue.
      But got ClusterException: Unable to get list of queues: Failed in an LSF library call

      Did you manage to resolve it ?

  13. Create a new configuration file for ld linker to pick your LSF shared libraries:
    $ echo $LSF_TOP
    /opt/openlava
    $ echo “$LSF_TOP/lib” > /etc/ld.so.conf.d/openlava-x86_64.conf
    $ cat /etc/ld.so.conf.d/openlava-x86_64.conf
    /opt/openlava/lib
    $ ldconfig -v | grep liblsf.so.0
    …..
    liblsf.so.0 -> liblsf.so.0.0.1

    If that doesn’t help then you might need to run chrpath or patchelf on bin/* and sbin/*, as well as lib/*

    As for the Unable to get list of queues error message, before you start python manage.py runserver …., make sure you are sourced you open lava enviroment (openlava.sh or openlava.csh), where you need define additional vars. From my experience I have these defined in openlava.csh and openlava-web seems to be working every time: LSF_ENVDIR, LSF_BINDIR, LSF_SERVERDIR, LSF_LIBDIR, LSF_HOME, LSF_TOP, LSF_SHAREDIR

  14. ClusterException at /
    Unable to get list of queues: Failed in an LSF library call
    Request Method: GET
    Request URL: http://rjcaews015:84/
    Django Version: 1.6.12
    Exception Type: ClusterException
    Exception Value:
    Unable to get list of queues: Failed in an LSF library call
    Exception Location: /opt/openlava_webui/openlavaweb/cluster/openlavacluster.py in raise_cluster_exception, line 262
    Python Executable: /bin/python
    Python Version: 2.7.5
    Python Path:
    [‘/opt/openlava_webui’,
    ‘/usr/lib/python2.7/site-packages/django_openlavaweb-1.1-py2.7.egg’,
    ‘/usr/lib64/python27.zip’,
    ‘/usr/lib64/python2.7’,
    ‘/usr/lib64/python2.7/plat-linux2’,
    ‘/usr/lib64/python2.7/lib-tk’,
    ‘/usr/lib64/python2.7/lib-old’,
    ‘/usr/lib64/python2.7/lib-dynload’,
    ‘/usr/lib64/python2.7/site-packages’,
    ‘/usr/lib64/python2.7/site-packages/gtk-2.0’,
    ‘/usr/lib/python2.7/site-packages’]
    Server time: Fri, 3 Jun 2016 15:55:10 +0000

  15. I am getting the following error when I access the django server:

    ImportError: /opt/openlava-3.3/lib/liblsbatch.so.0: undefined symbol: mergeResreq

    Any advice on how to resolve? I’ve tried building again but without much luck, full traceback is below:

    Quit the server with CONTROL-C.
    Internal Server Error: /
    Traceback (most recent call last):
    File “/usr/local/lib/python2.7/site-packages/django/core/handlers/base.py”, line 134, in get_response
    resolver_match = resolver.resolve(request.path_info)
    File “/usr/local/lib/python2.7/site-packages/django/core/urlresolvers.py”, line 376, in resolve
    sub_match = pattern.resolve(new_path)
    File “/usr/local/lib/python2.7/site-packages/django/core/urlresolvers.py”, line 376, in resolve
    sub_match = pattern.resolve(new_path)
    File “/usr/local/lib/python2.7/site-packages/django/core/urlresolvers.py”, line 248, in resolve
    return ResolverMatch(self.callback, args, kwargs, self.name)
    File “/usr/local/lib/python2.7/site-packages/django/core/urlresolvers.py”, line 255, in callback
    self._callback = get_callable(self._callback_str)
    File “/usr/local/lib/python2.7/site-packages/django/utils/lru_cache.py”, line 100, in wrapper
    result = user_function(*args, **kwds)
    File “/usr/local/lib/python2.7/site-packages/django/core/urlresolvers.py”, line 115, in get_callable
    mod = import_module(mod_name)
    File “/usr/lib64/python2.7/importlib/__init__.py”, line 37, in import_module
    __import__(name)
    File “/opt/openlava_webui/openlavaweb/views.py”, line 41, in
    from openlavaweb.cluster.openlavacluster import Cluster, Host, Job, Queue, User, ExecutionHost, NoSuchHostError
    File “/opt/openlava_webui/openlavaweb/cluster/openlavacluster.py”, line 22, in
    from openlava import lslib, lsblib
    ImportError: /opt/openlava-3.3/lib/liblsbatch.so.0: undefined symbol: mergeResreq

    • My assumption is that too much has changed between 2.2 and 3.3 for OpenLavaWeb to work with 3.3. I pulled 2.2 from the openlava github project and build from those sources, that allowed me to get the webserver up and running again. If anyone knows the latest version of OpenLava that works with openlavaweb I would greatly appreciate the information so I don’t have to keep trying (I’ve already tried 3.3 and 3.0).

  16. Hi.
    It not worked for me.
    When I run “python /opt/openlava_webui/manage.py runserver 0.0.0.0:80” I saw in the browser a debug page and in the terminal I got:

    System check identified no issues (0 silenced).
    July 08, 2016 – 09:28:03
    Django version 1.9.7, using settings ‘openlava_webui.settings’
    Starting development server at http://0.0.0.0:80/
    Quit the server with CONTROL-C.

    Internal Server Error: /
    Traceback (most recent call last):
    File “/opt/rh/python27/root/usr/lib64/python2.7/site-packages/django/core/handlers/base.py”, line 134, in get_response
    resolver_match = resolver.resolve(request.path_info)
    File “/opt/rh/python27/root/usr/lib64/python2.7/site-packages/django/core/urlresolvers.py”, line 376, in resolve
    sub_match = pattern.resolve(new_path)
    File “/opt/rh/python27/root/usr/lib64/python2.7/site-packages/django/core/urlresolvers.py”, line 376, in resolve
    sub_match = pattern.resolve(new_path)
    File “/opt/rh/python27/root/usr/lib64/python2.7/site-packages/django/core/urlresolvers.py”, line 248, in resolve
    return ResolverMatch(self.callback, args, kwargs, self.name)
    File “/opt/rh/python27/root/usr/lib64/python2.7/site-packages/django/core/urlresolvers.py”, line 255, in callback
    self._callback = get_callable(self._callback_str)
    File “/opt/rh/python27/root/usr/lib64/python2.7/site-packages/django/utils/lru_cache.py”, line 100, in wrapper
    result = user_function(*args, **kwds)
    File “/opt/rh/python27/root/usr/lib64/python2.7/site-packages/django/core/urlresolvers.py”, line 115, in get_callable
    mod = import_module(mod_name)
    File “/opt/rh/python27/root/usr/lib64/python2.7/importlib/__init__.py”, line 37, in import_module
    __import__(name)
    File “/opt/openlava_webui/openlavaweb/views.py”, line 41, in
    from openlavaweb.cluster.openlavacluster import Cluster, Host, Job, Queue, User, ExecutionHost, NoSuchHostError
    File “/opt/openlava_webui/openlavaweb/cluster/openlavacluster.py”, line 22, in
    from openlava import lslib, lsblib
    ImportError: /opt/openlava-3.3/lib/liblsbatch.so.0: undefined symbol: make_link
    [08/Jul/2016 09:28:05] “GET / HTTP/1.1” 500 110336
    [08/Jul/2016 09:28:05] “GET /favicon.ico HTTP/1.1” 404 8305
    .
    .

  17. gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong –param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong –param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/opt/openlava-3.2/include -I. -I/usr/include/python2.7 -c openlava/lsblib.c -o build/temp.linux-x86_64-2.7/openlava/lsblib.o -O3 -Wall
    In file included from /opt/openlava-3.2/include/lsbatch.h:26:0,
    from openlava/lsblib.c:274:
    /opt/openlava-3.2/include/lsf.h:19:0: warning: “_GNU_SOURCE” redefined [enabled by default]
    #define _GNU_SOURCE
    ^
    In file included from /usr/include/python2.7/pyconfig.h:6:0,
    from /usr/include/python2.7/Python.h:8,
    from openlava/lsblib.c:4:
    /usr/include/python2.7/pyconfig-64.h:1160:0: note: this is the location of the previous definition
    #define _GNU_SOURCE 1
    ^
    openlava/lsblib.c: In function ‘__pyx_pf_8openlava_6lsblib_9JobMsgLog_5usrId___get__’:
    openlava/lsblib.c:44539:55: error: ‘struct jobMsgLog’ has no member named ‘usrI ’
    __pyx_t_1 = __Pyx_PyInt_From_int(__pyx_v_self->_data->usrId); if (unlikely(!__pyx_t_1)) __PYX_ERR(0, 4512, __pyx_L1_error)
    ^
    openlava/lsblib.c: In function ‘__pyx_pf_8openlava_6lsblib_9JobMsgLog_5msgId___get__’:
    openlava/lsblib.c:44659:55: error: ‘struct jobMsgLog’ has no member named ‘msgI ’
    __pyx_t_1 = __Pyx_PyInt_From_int(__pyx_v_self->_data->msgId); if (unlikely(!__pyx_t_1)) __PYX_ERR(0, 4522, __pyx_L1_error)
    ^
    openlava/lsblib.c: In function ‘__pyx_pf_8openlava_6lsblib_9JobMsgLog_4type___get__’:
    openlava/lsblib.c:44719:55: error: ‘struct jobMsgLog’ has no member named ‘type’
    __pyx_t_1 = __Pyx_PyInt_From_int(__pyx_v_self->_data->type); if (unlikely(!__pyx_t_1)) __PYX_ERR(0, 4527, __pyx_L1_error)
    ^
    openlava/lsblib.c: In function ‘__pyx_pf_8openlava_6lsblib_9JobMsgLog_3src___get__’:
    openlava/lsblib.c:44780:59: error: ‘struct jobMsgLog’ has no member named ‘src’
    __pyx_t_1 = __Pyx_PyBytes_FromString(__pyx_v_self->_data->src); if (unlikely(!__pyx_t_1)) __PYX_ERR(0, 4532, __pyx_L1_error)
    ^
    openlava/lsblib.c: In function ‘__pyx_pf_8openlava_6lsblib_9JobMsgLog_4dest___get__’:
    openlava/lsblib.c:44845:59: error: ‘struct jobMsgLog’ has no member named ‘dest’
    __pyx_t_1 = __Pyx_PyBytes_FromString(__pyx_v_self->_data->dest); if (unlikely(!__pyx_t_1)) __PYX_ERR(0, 4537, __pyx_L1_error)
    ^
    error: command ‘gcc’ failed with exit status 1

Leave a Reply

Your email address will not be published. Required fields are marked *