...
The standard implementation of JobControlClient uses Java Remote Method Invocation (RMI) to communicate with the server, so it should be quite possible for the daemon to run on a remote site. There may be some issues with firewall's at remote sites, but the server can be configured to run on any port, and only requires incoming connections to be allowed from a small set of hosts at SLAC where we run the pipeline II server.
Tip |
---|
We expect a remote JobControlService to be implemented to talk directly to the batch system at remote sites. Another possibility would be to implement a JobControlService which could talk to a Grid job control system. This would have the potential advantage of allowing a single implementation of JobControlService to work with any site implementing the specific GRID job control system. We have not currently given much though to the potential pitfalls with such an approach, but it may be worth considering. |
Once a JobControlService is available which allows submission to remote site we will need to set up the pipeline II server to work with it. While the server was designed to allow this it has not yet been tried, and going from one site to more than one sight will certainly require some work to allow additional configuration of the server
In addition to the JobControlService any GLAST software actually required to run the (MC) tasks at the remote site will need to be installed. We will need to adopt some standard mechanism for locating and setting up GLAST software at remote sites (for example defining GLAST_ROOT and perhaps some standard setup scripts).
Pipeline II allows task developers a great deal of freedom in how they set up specific tasks to run in the server. Up to now all tasks have been designed to run at SLAC, and typically have hard-wired paths to known file locations at SLAC. Once the pipeline server and remote JobControlService are set up we will need to work with task developers to set up tasks in a site independent manner.