Installation

No officially packaged release exists yet. The instructions below are temporary instructions for advanced users (ie, should not pose problems for a typical cluster admin), people who want to see what the new github hosted code can do, as well as for people who are interested in becoming developers or contributors.

Prior to Installation

  1. Grid Engine 6.2 should be installed and functioning. Earlier versions of Grid Engine produce different XML output and may not be supported well.
  2. Make sure you have Perl available – it is needed for the HTTPi webserver, by the caching daemon and by some configuration scripts.

Installation Steps – HTTPi

Configuring and installing the HTTPi-based web application should be very easy.

  1. Checkout or download xml-qstat from github.com
  2. Execute the make-httpi.sh script to create and install a customized version of the httpi webeserver. You will be prompted for various configuration and installation parameters as described in the installation instructions.
  3. Start the httpi webserver.
  4. The web interface should be ready for testing. Direct a web browser at the URL http://{host}:8080/grid/, the host and port number depending on your configuration.
  5. Use the web-app/config/config.xml file to set any local configuration parameters (details below).

Installation Steps – Cocoon

Configuring and installing the cocoon-based web application is relatively easy, but may depend on which version of Java you have installed on your system.

  1. Checkout or download xml-qstat from github.com
  2. Install Cocoon
  3. Start the cocoon webserver.
  4. The web interface should be ready for testing. Direct a web browser at the URL http://{host}:8888/grid/, the host and port number depending on your configuration.
  5. Use the web-app/config/config.xml file to set local configuration parameters (details are below).

Customizing the config/

Within the web-app/config/ directory, a config.xml file can be used to reflect the local site installation. The config.xml.EXAMPLE file is well documented internally and provides an example of possible contents. The file web-app/config/logo.png contains the default logo to be displayed at the top of each page. Note that neither web-app/config/config.xml nor web-app/config/logo.png are tracked in git, thus your changes there will not be overwritten if you update the software.

Using Cached Grid Engine XML

To reduce load on the qmaster and avoid calling ‘qstat’ each time a page is accessed, cached SGE data can be used. A script in the scripts/ directory called “xmlqstat-cacher.pl” can perform this function. The cache location is defined by how the cluster is named in config/config.xml.

Create a web-app/cache-{NAME} directory, where {NAME} corresponds to the cluster name defined in the config.xml file. The application will automatically detect the presence of the cache directory, when this naming and location convention is followed.

  • The xmlqstat-cacher.pl program will create the needed cache files “qstat.xml”, “qstatf.xml” and “qhost.xml”.
  • The qlicserver program can be instructed to create the needed cache files “qhost.xml”, “qstat.xml” and “qlicserver.xml”.

Caching qstat -f output

Edit the scripts/sge-xml-cacher.pl script to configure the full Unix file path to where cached SGE status data will be stored. The data should typically be stored within the web-app/cache/ directory as “qstatf.xml”. For a multi-cluster view, the file should be stored as web-app/cache/qstatf~{NAME}.xml or as web-app/cache-{NAME}/qstatf.xml, where {NAME} is the name given to the cluster. This convention should be followed, otherwise severe editing of the sitemap.xmap and/or the customized HTTPi will be required.

Check that the SGE environment has been set up (you can run ‘qstat’ via the command line), then starting the perl caching daemon should be as simple as issuing the command “scripts/xmlqstat-cacher.pl -d”. To stop the daemon, issue the command “scripts/xmlqstat-cacher.pl -k”. To verify that the daemon is working, check the process table to see if it exists and then monitor the timestamps on the cache file. In its default setting, XML data should be updated every 30 seconds.

Using cached data from qlicserver

If you are running the qlicserver on your system, its cached data can be reused here. The qlicserver already gathers some ‘qstat’ information as part of its heuristics. To complete the xmlqstat integration, you should also have it cache a ‘qhost’ query:

    dir=/some/path/cache \
    output=qlicserver.xml \
    qhost=qhost.xml \
    qstat=qstat.xml

And then link it back into the xmlqstat/web-app/ directory under the corresponding cluster name. For example,

    $ ln -s /some/path/cache /opt/grid/xml-qstat/web-app/cache-NAME

where the cache-{NAME} convention has been described above.