GEO600
The Search for Gravitational Waves using the GRID
  • Deployment
  • Configuration
  • Testing
  • Workflow

    • Content

    • Introduction
    • The Deployment Project
    • CODE Deployment
    • CODE Deployment Configuration
    • GRID Deployment
    • GRID Deployment Configuration
    • FAQ
    • Introduction
    • Grid Deployment is the key to successfully scale an application to any GRID. While a wide range of GRID Resources might be available within a grid infrastructure, it is the deployment process which ultimately decides on which resource an application will run and on which it will not.
    • The AstroGrid-D Deployment Project aims to successfully bridge between a managed software project and its deployment on the grid by providing distribution and build tools suitable for grid environments. Using the deployment project the grid user may always choose from several ways to accomplish a task instead of depending on one way only.
    • The GEO600 Grid Application uses the AstroGrid-D Deployment Project to reach all major grid resources in D-Grid which in turn provide one million cpu hours every month to the search for gravitational waves.
    • The AstroGrid-D Deployment Project
    • The deployment project is an open source project protected by the Apache License. You may checkout the sources of the project using subversion:
    • svn --username anonymous --password "" co svn://svn.gac-grid.org/software/deployment
    • In order to successfully deploy GEO600 on any grid resource, it is recommended to have a brief understanding about the deployment process which is split into two independent parts. The first part concerns the location of software and how to build it on a grid resource. The second part is complementary to the first and concerns the distribution of individual deployment tasks to grid resources.
    • In the folder deployment/main/scripts you will find two applications which divide and conquer the deployment process into these two independent parts.
    • The first application called deploy.pl will always run on the grid resource where the deployment process takes place. It is responsible for building code locally at any grid resource.
    • The second application is called submit.pl and steers the deployment process from a single grid resource. This application supports the submission of deployment jobs to grid resources which will execute deploy.pl locally on a grid resource.
    • CODE Deployment
    • The local deployment process is governed by deploy.pl. 
    • robert@buran:~/scratch/deployment/main/scripts> perl deploy.pl -help
Usage:
            perl deploy.pl
        
            Options:
                    -help               display this message
                    -man                display man page
                    -verbose|v          print debug messages
                    -clean              clean up everything from previous deployments before new deployment
                    -logfile            specify the location of the log file
                    -report             specify the location of the report file
                    -config             specify the location of the deployment configuration file
    • deploy.pl relies on a deployment configuration file describing what software should be installed, where the source code is located and how it should be build.
    • The GEO600 grid application relies on a number of software packages to be installed using the deployment project.
    • BOINC: 5.3.31_i686, 5.4.11_i686, 5.8.16_i686, 5.10.21_i686, 5.10.21_x86_64, 5.10.28_i686
    • squid-2.6
    • ncurses-5.6
    • mysql-5.0.37
    • Time::HiRes
    • DBI
    • DBD::mysql
    • Term::Size
    • Term::StatusBar
    • The deployment process will build and install all packages in this order and assure that all components work well together. You can test the deployment process locally by changing to deployment/main/scripts and executing: 
    • robert@ikarus:~/deployment/main/scripts$ perl deploy.pl -config=../etc/GEO600/deploy-devel.conf


 DEPLOY                 SOURCE   UNPACK     TYPE  CONFIGURE   MAKE    INSTALL   RC TIME[s]
-------------------------------------------------------------------------------------------
 GEO600-devel           r.5468   skipped     SVN   skipped   skipped  skipped    0      0
 boinc_5.3.31_i686        OK       OK         SH   skipped   skipped    OK       0      0
 boinc_5.4.11_i686        OK       OK         SH   skipped   skipped    OK       0      1
 boinc_5.8.16_i686        OK       OK         SH   skipped   skipped    OK       0      2
 boinc_5.10.21_i686       OK       OK         SH   skipped   skipped    OK       0      3
 boinc_5.10.21_x86_64     OK       OK         SH   skipped   skipped    OK       0      3
 boinc_5.10.28_i686       OK       OK         SH   skipped   skipped    OK       0      2
 archive                  OK       OK              skipped   skipped    OK       0      0
 archive-beta             OK       OK              skipped   skipped    OK       0      1
 squid                    OK     skipped     GNU   skipped   skipped  skipped    0      0
 ncurses                  OK     skipped     GNU   skipped   skipped  skipped    0      0
 mysql                    OK     skipped     GNU   skipped   skipped  skipped    0      0
 Time::HiRes              OK       OK       PERL     OK        OK       OK       0      8
 DBI                      OK       OK       PERL     OK        OK       OK       0     18
 DBD::mysql               OK       OK       PERL     OK        OK       OK       0     13
 Term::Size               OK       OK       PERL     OK        OK       OK       0      2
 Term::StatusBar          OK       OK       PERL     OK        OK       OK       0      1

2008/02/29 15:50:58 INFO> report= /home/robert/deployment/log/ikarus.aei.mpg.de.rep
2008/02/29 15:50:58 INFO> log   = /home/robert/deployment/log/ikarus.aei.mpg.de.log
    • Running deploy.pl for the first time will likely take some time to complete. Every successive call of deploy.pl will only take a fraction of the time since packages will in general not be rebuild. A rebuild can of course be requested in the deployment configuration file. This is especially convinient in order to partially update code in grid environments.
    • When the deployment process completes a detailed log file and deployment report will be generated in deployment/log.
    • GRID Deployment
    • The grid deployment process is controlled by submit.pl 
    • robert@buran:~/scratch/deployment/main/scripts> perl submit.pl -help
Usage:
            perl submit.pl
        
            Options:
                    -help                 display this message
                    -man                  display man page          
                    -status               check status of running deployment task
                    -poststage            poststage all deployment data to this host
                    -host                 FQDN of grid host to deploy on
                    -config               deployment configuration file
                    -executable           deployment application
                    -factory-type         defines the factory type
                    -queue                defines the queue name on the remote machine
                    -epr                  connect to database and store epr into a file, requires -id=
                    -verbose|v            turn on debug messages
                    -svn-user             svn user name
                    -svn-pass             svn pass
                    -list|l               list all hosts found in configuration file
    • submit.pl relies on a configuration file describing the grid resources used in the deployment process. See the two examples below for a grid workstation and a grid cluster for valid entries in the grid deployment configuration file.
    • An entry describing a grid workstation must specify the location of the deployment CONFIG file for the grid resource and the location of the deployment EXECUTABLE. The deployment project supports many protocols to fetch these files from remote locations such as http, ftp, svn, gsiscp and gsiftp. The deployment application deploy.pl must be wrapped by the shell script deploy.sh, because the path to the Perl program is not known to Globus.
    • The example below describes the grid deployment configuration for a grid workstation with the fully qualified domain name supergrid.aei.mpg.de. The deployment configuration file and the deployment executable will both be staged in from buran.aei.mpg.de using gsiftp. After completion of the deployment task on supergrid.aei.mpg.de, STDOUT, STDERR, LOG and the deployment REPORT will be staged out to buran.aei.mpg.de. 
    • deploy supergrid.aei.mpg.de {
	CONFIG      = gsiftp://buran.aei.mpg.de/store/deployment/main/etc/GEO600/deploy-devel.conf
	EXECUTABLE  = gsiftp://buran.aei.mpg.de/store/deployment/main/bin/deploy.sh
	LOGNAME     = supergrid.aei.mpg.de.devel
	STDOUT      = gsiftp://buran.aei.mpg.de/store/deployment/log/$DN/supergrid.aei.mpg.de.devel.out
	STDERR      = gsiftp://buran.aei.mpg.de/store/deployment/log/$DN/supergrid.aei.mpg.de.devel.err
	LOG         = gsiftp://buran.aei.mpg.de/store/deployment/log/$DN/supergrid.aei.mpg.de.devel.log
	REPORT      = gsiftp://buran.aei.mpg.de/store/deployment/log/$DN/supergrid.aei.mpg.de.devel.rep
}
    • An entry describing a grid cluster in the grid deployment configuration builds on the same syntax as it has been used in the former example for a grid workstation. However a grid cluster might require special settings for the port number of the gramws job-manager and the factory type supported. In the example below the deployment task will be submitted to the SGE queue running at osg.hpcc.nd.edu. 
    • deploy osg.hpcc.nd.edu {
	CONFIG      = gsiftp://buran.aei.mpg.de/store/deployment/main/etc/GEO600/deploy-devel.conf
	EXECUTABLE  = gsiftp://buran.aei.mpg.de/store/deployment/main/bin/deploy.sh
	STDOUT      = gsiftp://buran.aei.mpg.de/store/deployment/log/$DN/osg.hpcc.nd.edu.out
	STDERR      = gsiftp://buran.aei.mpg.de/store/deployment/log/$DN/osg.hpcc.nd.edu.err
	LOG         = gsiftp://buran.aei.mpg.de/store/deployment/log/$DN/osg.hpcc.nd.edu.log
	REPORT      = gsiftp://buran.aei.mpg.de/store/deployment/log/$DN/osg.hpcc.nd.edu.rep
	GRAMWS_PORT = 9443
	FT          = SGE
}
    • As a practical example consider buran.aei.mpg.de as a grid workstation having the Globus Toolkit installed and you want to use it to deploy GEO600 on another grid workstation called supergrid.aei.mpg.de. Deploying GEO600 on supergrid.aei.mpg.de essentially consists of creating an entry for supergrid.aei.mpg.de in the grid deployment configuration file as shown above and simply executing on buran.aei.mpg.de: 
    • robert@buran:~> perl submit.pl -config=../etc/GEO600/grid-deploy-devel.conf -host=supergrid.aei.mpg.de
2008/02/29 19:13:03 INFO> deployment task submission to supergrid.aei.mpg.de completed
    • This command creates a job description for the deployment task on supergrid.aei.mpg.de in deployment/log/supergrid.aei.mpg.de.devel.rsl and is followed by a job submission to the web service interface of GRAMWS running on supergrid.aei.mpg.de:8443. The job contact is saved to deployment/log/supergrid.aei.mpg.de.devel.epr in order to trigger the status of the deployment task: 
    • robert@buran:~> perl submit.pl -config=../etc/GEO600/grid-deploy-devel.conf -host=supergrid.aei.mpg.de -status
2008/02/29 19:13:07 INFO> deployment on supergrid.aei.mpg.de in state StageIn
    • Which notifies us about the deployment configuration file and the deployment executable being staged in to supergrid.aei.mpg.de. After StageIn the task will be flagged as Active and Done when the deployment task completed. In this case the status query will yield: 
    • robert@buran:~> perl submit.pl -config=../etc/GEO600/grid-deploy-devel.conf -host=supergrid.aei.mpg.de -status
2008/02/29 19:19:27 INFO> deployment on supergrid.aei.mpg.de in state Done

 DEPLOY                 SOURCE   UNPACK     TYPE  CONFIGURE   MAKE    INSTALL   RC TIME[s]
-------------------------------------------------------------------------------------------
 GEO600-devel           r.5481   skipped     SVN   skipped   skipped  skipped    0      0
 boinc_5.3.31_i686        OK       OK         SH   skipped   skipped    OK       0      3
 boinc_5.4.11_i686        OK       OK         SH   skipped   skipped    OK       0      3
 boinc_5.8.16_i686        OK       OK         SH   skipped   skipped    OK       0      4
 boinc_5.10.21_i686       OK       OK         SH   skipped   skipped    OK       0      3
 boinc_5.10.21_x86_64     OK       OK         SH   skipped   skipped    OK       0      5
 boinc_5.10.28_i686       OK       OK         SH   skipped   skipped    OK       0      3
 archive                  OK       OK              skipped   skipped    OK       0      0
 archive-beta             OK       OK              skipped   skipped    OK       0      3
 squid                    OK     skipped     GNU   skipped   skipped  skipped    0      0
 ncurses                  OK     skipped     GNU   skipped   skipped  skipped    0      0
 mysql                    OK     skipped     GNU   skipped   skipped  skipped    0      0
 Time::HiRes              OK       OK       PERL     OK        OK       OK       0     19
 DBI                      OK       OK       PERL     OK        OK       OK       0     34
 DBD::mysql               OK       OK       PERL     OK        OK       OK       0     29
 Term::Size               OK       OK       PERL     OK        OK       OK       0      4
 Term::StatusBar          OK       OK       PERL     OK        OK       OK       0      2
    • After the deployment task completed the stdout, stderr, log and the deployment report will be staged out to the location specified in the grid deployment configuration file.
    • CODE Deployment Configuration
    • At the heart of the Deployment Project exist two configuartion files steering the deployment of software locally at a grid resource on one side and defining the grid resources targeted by the deployment on the other side. This section aims to describe the syntax used in the code deployment configuration file.
    • It is not neccessary to read this section if you just want to deploy the GEO600 grid application as defined in deployment/main/etc/GEO600/deploy-devel.conf !
    • The code deployment configuration file consists of several sections called deploy followed by a descriptive name: 
    • deploy GEO600-devel {
}

deploy squid {
}
    • The Deployment Project aims to ease dependencies of software packages by building them one after another as described by the order of appearance in the code deployment configuration file.
    • An empty deploy section will not trigger any actions to be taken. To get sources to a resource, it is therefor important to specify their LOCATION or the REPOSITORY which provides them: 
    • deploy GEO600-devel {
	REPOSITORY  = svn://svn.gac-grid.org/software/GEO600/branches/trunc
	DESTINATION = $HOME/GEO600-devel
	SVN_USER    = anonymous
	SVN_PASS    = ""
	UPDATE      = 1
}

deploy squid {
	LOCATION    = http://www.squid-cache.org/Versions/v2/2.6/squid-2.6.STABLE13.tar.gz
	DESTINATION = $HOME/GEO600-devel/src/squid-2.6.STABLE13.tar.gz
	UPDATE      = 0
}
    • A LOCATION specifies a full URI pointing to a download location. It can either use ftp and http without authentication or gsiscp and gsiftp with grid certificate authentication. Download of a single file using svn is also supported.
    • A REPOSITORY specifies a full URI pointing to a repository. At the present time only svn repositories using anonymous authentication or username / password authentication are supported. If your use case is hosted by a different repository please contact me and I will add support as soon as possible.
    • The keyword DESTINATION specifies the location on the file system after the download or checkout from a remote location completed. Using the UPDATE keyword it is possible to update the sources hosted by a repository or to skip repeated downloads of files located at web locations.
    • The REPOSITORY and LOCATION key words increase the flexibility of placing code or data on a grid resource beyond the basic possibilities Globus supports. The deployment project can act further on your sources in dependence of the existence of additional options in the configuration file.
    • The keyword PACKAGE points to the location of a software package on the file system that needs to be unpacked. Currently supported are compressed and uncompressed tar archives recognized by the prefix .tar, .tar.gz and .tgz. If PACKAGE points to the location of a shell script, the script is simply being executed. 
    • deploy squid {
	LOCATION    = http://www.squid-cache.org/Versions/v2/2.6/squid-2.6.STABLE13.tar.gz
	DESTINATION = $HOME/GEO600-devel/src/squid-2.6.STABLE13.tar.gz
	UPDATE      = 0
	PACKAGE     = $HOME/GEO600-devel/src/squid-2.6.STABLE13.tar.gz
	SOURCE      = $HOME/GEO600-devel/src/squid-2.6.STABLE13
}
    • By default the package will be unpacked into the same directory $HOME/GEO600-devel/src. It is assumed that after unpacking the package a new subdirectory with the name of the package $HOME/GEO600-devel/src/squid-2.6.STABLE13 will exist. In general this is often but not always the case. In these cases one can specify the newly created subdirectory by using the SOURCE keyword.
    • At this point we can place software or data on grid resources. We can also unpack archives and execute shell scripts if needed. The Deployment Project also supports building managed C/C++/Fortran and Perl projects.
    • In the case of a managed C/C++/Fortran project, deploy.pl is looking for the existence of configure in the root directory of the software package and subsequently triggers the execution of configure, make and make install.
    • The installation prefix can be handed to configure by using the PREFIX keyword in the configuration file. It is also possible to hand just any additional option to configure by using the EXTRA keyword in the configuration file. 
    • deploy squid {
	LOCATION    = http://www.squid-cache.org/Versions/v2/2.6/squid-2.6.STABLE13.tar.gz
	DESTINATION = $HOME/GEO600-devel/src/squid-2.6.STABLE13.tar.gz
	UPDATE      = 0
	PACKAGE     = $HOME/GEO600-devel/src/squid-2.6.STABLE13.tar.gz
	SOURCE      = $HOME/GEO600-devel/src/squid-2.6.STABLE13
	PREFIX      = $HOME/GEO600-devel/build/squid-2.6
	EXTRA       = "--prefix=$HOME/GEO600-devel/build/squid-2.6"
}
    • In the case of a managed Perl project, deploy.pl is looking for the existence of a file called Makefile.PL in the root directory of the software package and executes perl Makefile.PL, make and make install. 
    • deploy Time::HiRes {
	PACKAGE     = $HOME/GEO600-devel/src/Time-HiRes-1.9707.tar.gz
	EXTRA       = "PREFIX=$HOME/perl/"
}
    • At this point we are able to build and install managed C/C++/Fortran and Perl projects. Three additional keywords will allow us to specify how rebuilds should be handed. The keyword FILE may point to the location of a file which if present will skip a rebuild. Similar the keyword BINARY may point to a binary which if present will skip a rebuild. A rebuild can also be forced by setting the keyword CLEAN to "1" or "yes". 
    • deploy squid {
	LOCATION    = http://www.squid-cache.org/Versions/v2/2.6/squid-2.6.STABLE13.tar.gz
	DESTINATION = $HOME/squid-2.6.STABLE13.tar.gz
	UPDATE      = 0
	PACKAGE     = $HOME/squid-2.6.STABLE13.tar.gz
	SOURCE      = $HOME/squid-2.6.STABLE13
	PREFIX      = $HOME/squid-2.6
	EXTRA       = "--prefix=$HOME/squid-2.6"
	BINARY      = squid
}

deploy Time::HiRes {
	PACKAGE     = $HOME/GEO600-devel/src/Time-HiRes-1.9707.tar.gz
	EXTRA       = "PREFIX=$HOME/perl/"
	FILE        = "Time/HiRes.pm"
}
    • If you place the deploy section for Squid above into the file ~/tmp/squid.conf and execute in deployment/main/scripts
    • perl deploy.pl -config=~/tmp/squid.conf
    • you will be able to deploy Squid onto your local machine in under two minutes. 
    • 					
robert@ikarus:~/deployment/main/scripts$ perl deploy.pl -config=/home/robert/tmp/squid.conf -v


 DEPLOY                 SOURCE   UNPACK     TYPE  CONFIGURE   MAKE    INSTALL   RC TIME[s]
-------------------------------------------------------------------------------------------
 squid                    OK       OK        GNU     OK        OK       OK       0     63

2008/03/03 22:31:33 INFO> report= /home/robert/deployment/log/ikarus.rep
2008/03/03 22:31:33 INFO> log   = /home/robert/deployment/log/ikarus.log
    • Executing the above statement again will skip all actions since the binary is already present. 
    • 					
robert@ikarus:~/deployment/main/scripts$ perl deploy.pl -config=/home/robert/tmp/squid.conf -v


 DEPLOY                 SOURCE   UNPACK     TYPE  CONFIGURE   MAKE    INSTALL   RC TIME[s]
-------------------------------------------------------------------------------------------
 squid                    OK     skipped     GNU   skipped   skipped  skipped    0      0

2008/03/03 22:36:04 INFO> report= /home/robert/deployment/log/ikarus.rep
2008/03/03 22:36:04 INFO> log   = /home/robert/deployment/log/ikarus.log
    • GRID Deployment Configuration
    • An example of a grid deployment configuration file was already shown above. This section aims to demonstrate how to construct a valid machine entry for a grid resource in the grid deployment configuration file.
    • It is not neccessary to read this section if you just want to deploy GEO600 on a grid resource that has already been configured in deployment/main/etc/GEO600/grid-deploy-devel.conf !
    • A host entry in the grid deployment configuration file consists of the keyword deploy followed by the fully qualified domain name of the grid resource.
    • The keyword CONFIG specifies a full URI pointing to the location of the code deployment configuration file used for the deployment process on the grid resource. This file can be provided by a web server using http or ftp, by a grid resource supporting gsiftp or gsiscp or by a svn repository.
    • The keyword EXECUTABLE specifies a full URI pointing to the location of the shell script wrapping deploy.pl. This script is part of the Deployment Project and is located in deployment/main/bin/deploy.sh. 
    • 					
deploy nest.phys.uwm.edu {
	CONFIG     = gsiftp://buran.aei.mpg.de/store/deployment/main/etc/GEO600/deploy-devel.conf
	EXECUTABLE = gsiftp://buran.aei.mpg.de/store/deployment/main/bin/deploy.sh
}
    • Both files will be staged to the grid resource. The functionality of deploy.sh covers the search for mandatory programs on the grid resource and the checkout of the Deployment Project using svn. The code deployment configuration file is then handed over to deploy.pl upon its execution which triggers the deployment on the grid resource.
    • If the grid resource does not provide svn it is possible to stage in a static binary of svn as provided by the Deployment Project in deployment/main/bin/svn 
    • 					
deploy nest.phys.uwm.edu {
	CONFIG      = gsiftp://buran.aei.mpg.de/store/deployment/main/etc/GEO600/deploy-devel.conf
	EXECUTABLE  = gsiftp://buran.aei.mpg.de/store/deployment/main/bin/deploy.sh
	SVN         = gsiftp://buran.aei.mpg.de/store/deployment/main/bin/svn
}
    • On many grid resources interactive login sessions using gsissh will be blocked. In this case it is convinient to stage out STDOUT, STDERR, LOG and the deployment REPORT using these keywords. 
    • 					
deploy nest.phys.uwm.edu {
	CONFIG      = gsiftp://buran.aei.mpg.de/store/deployment/main/etc/GEO600/deploy-devel.conf
	EXECUTABLE  = gsiftp://buran.aei.mpg.de/store/deployment/main/bin/deploy.sh
	SVN         = gsiftp://buran.aei.mpg.de/store/deployment/main/bin/svn
	STDOUT      = gsiftp://buran.aei.mpg.de/store/deployment/log/nest.phys.uwm.edu.out
	STDERR      = gsiftp://buran.aei.mpg.de/store/deployment/log/nest.phys.uwm.edu.err
	LOG         = gsiftp://buran.aei.mpg.de/store/deployment/log/nest.phys.uwm.edu.log
	REPORT      = gsiftp://buran.aei.mpg.de/store/deployment/log/nest.phys.uwm.edu.rep
}
    • At this point we assume that GRAMWS on the grid resource provides the Fork job-manager by default and is accepting connections on the default port 8443. The default values can be changed by using the keywords FT and GRAMWS_PORT. 
    • 					
deploy nest.phys.uwm.edu {
	CONFIG      = gsiftp://buran.aei.mpg.de/store/deployment/main/etc/GEO600/deploy-devel.conf
	EXECUTABLE  = gsiftp://buran.aei.mpg.de/store/deployment/main/bin/deploy.sh
	SVN         = gsiftp://buran.aei.mpg.de/store/deployment/main/bin/svn
	STDOUT      = gsiftp://buran.aei.mpg.de/store/deployment/log/nest.phys.uwm.edu.out
	STDERR      = gsiftp://buran.aei.mpg.de/store/deployment/log/nest.phys.uwm.edu.err
	LOG         = gsiftp://buran.aei.mpg.de/store/deployment/log/nest.phys.uwm.edu.log
	REPORT      = gsiftp://buran.aei.mpg.de/store/deployment/log/nest.phys.uwm.edu.rep
	FT          = Condor
	GRAMWS_PORT = 9443
}
    • Many grid resources use reasonable default values for other resource specific configuration options. However it is possible to set following variables in the grid deployment configuration file if needed: 
    • 	QUEUE       = "name of the queue to be used on the grid resource"
	JOBTYPE     = single
	MAXMEMORY   = "max main memory requested by the job in MB"
	MINMEMORY   = "min main memory requested by the job in MB"
	MAXWALLTIME = "max walltime requested by the job in minutes"
    • Frequently Asked Questions
    • How exactly are sources staged to the grid resource for deployment?

    • This is handled different for the code deployment and the grid deployment configuration file.

      Each statement in the code deployment configuration file is executed on the grid resource. If you specified a web server or a repository in the code deployment configuration file we assume that outgoing traffic to these resources is allowed from the grid resource. If this is not the case it is recommended to provide these sources on a resource you can access from the grid resource.

      Each statement in the grid deployment configuration file is executed on the submission host. If you specified a web server or a repository in the grid deployment configuration file we assume that outgoing traffic to these resources is allowed from the submission host. We download these sources to the submission host first and further use Globus to stage these sources to the grid resource using gsiftp.

    • My grid resource is the frontend to a cluster. The frontend differs in architecture and / or software environment from the cluster internal compute nodes. How should I deploy my code in this situation?

    • It is recommended to have two code deployment configuration files reflecting the differences between the frontend and the compute nodes. If the frontend and the compute nodes share a common file system like $HOME, it is recommended to specify different subdirectories for each installation in the code deployment configuration file. The grid deployment configuration can only have one entry for the grid resource. In this case it is neccessary to alter the factory-type FT between Fork and the name of the local queuing system like PBS and submit the deployment job twice. I am working on a better solution.

    • My grid resource is the frontend to a cluster. The frontend differs in architecture and / or software environment from the cluster internal compute nodes. The compute nodes do not allow outgoing traffic at all. How should I deploy my code in this situation?

    • The situation is simmilar to the previous question. Running the deployment task on the frontend first will assure that all sources are available when running the deployment task on the compute nodes. The deployment application deploy.pl will report an error message that sources could not be downloaded or fetched from a repository, but continue to build upon finding the sources on the local file system.

    • Robert Engel, Max-Planck Institut for Gravitational Physics