In previous entries it was stated the importance of the interoperability in the Grid computing and the use of adapters to obtain it. In this sense, GridWay provides a set of adapters based on Middleware Access Drivers (MADs), which allows the interoperation of three important infrastructures namely, EGEE (preWS gLite-based), TeraGrid and OSG (both Globus-based). The WS-based CREAM service provides a set of job management operations via the Web Service Description Language (WSDL). This new service is incompatible with the LCG pre-WS infrastructure. Therefore, it is necessary the development of a new GridWay adapter, based on MAD drivers, to enable the interoperability between CREAM and the rest of the existing infrastructures.
CREAM Service
The CREAM (Computing Resource Execution And Management) service is a lightweight and simple service that accepts job submission and management operations at the Computer Element level. These requests are described using the Job Description Language (JDL). The JDL language is a user-oriented and high-level language based on Condor classified advertisements (classads) for describing jobs to be submitted to the CREAM CE service.
In order to execute the job operations in CREAM infrastructure it is necessary to delegate the user proxy credential. This credential is used when the operations requiring security support have to be performed by the job. To delegate the proxy credential the user must execute the commands glite-ce-delegate-proxy, in the case of new delegations, or glite-ce-proxy-renew, to renew an existing delegation.
CREAM provides a CLI and C++ API to submit and manage the CREAM jobs. We have used the C++ API to develop a new adapter that allows the submission, cancel and polling of CREAM jobs using GridWay metascheduler.
CREAM MAD for GridWay Metascheduler
The new GridWay execution adapter for CREAM (denominated gw_em_mad_cream) allows the execution of jobs in EGEE infrastructure with CREAM-based CEs. Therefore, using a single GridWay instance with the appropriate adapter we can interoperate with LCG pre-WS and CREAM infrastructures. The figure below shows an example of GridWay interoperation between LCG pre-WS and CREAM.
GridWay provides a wrapper module that includes all needed information to execute a job. Due to the CREAM nodes are not home-shared, the GridWay wrapper is the responsible for transferring the executable input and output files. These transfers are done via the GASS (Global Access to Secondary Storage) server, installed in the User Interface (UI) node, and the globus-url-copy command. However, we found some difficulties when we want to transfer the wrapper input and output files using the CREAM JDL Template. The CREAM Job Description Language specifies that the staging-in must be done by the user and before the job (in this case is the wrapper module) execution. Therefore, the CREAM MAD must include the sentences globus-url-copy needed to transfer the wrapper input files via the GridFTP server installed in the CE (Computer Element) node. On the other hand, the staging-out is automatically done by CREAM using a GridFTP server that must be installed in the destination node. However, the standard UI specifications do not include the installation of a GridFTP server. In order to solve this restriction, CREAM MAD executes an epilogue module, using the JDL language, which transfers the wrapper output files via the GASS server installed in all standard UI nodes.
Finally, it is important to remark that the current implementation of CREAM MAD obtains the job status in synchronous way. Therefore, GridWay is the responsible to check the job status sending a poll request to this MAD. However, CREAM provides a way to obtain the asynchronous job status using the ICE (a gSOAP/C++ intermediate layer) and the CEMon service. Hence, we will use the CEMon service in the next CREAM adapter release to obtain the asynchronous CREAM job status via the GridWay metascheduler.
Simple CREAM job execution example
This section shows the behavior of GridWay adapter for CREAM in the execution of simple jobs. First, we configure the GridWay metascheduler to use CREAM adapter including the following sentences in the gwd.conf file:
###############################################
# Example MAD Configuration for CREAM testbed #
###############################################
IM_MAD = mds2_static:gw_im_mad_static:-l etc/im_examples/cream.hosts:dummy:cream
EM_MAD = cream:gw_em_mad_cream::jdl
TM_MAD = dummy:gw_tm_mad_dummy:-g
Next, we execute gwd command and show the execution hosts with gwhost command. In the screen capture below we can see that the CREAM machine is included in the available resources list.
Now, to demonstrate the GridWay interoperability we execute two jobs in the CREAM and the LCG infrastructure using the GW Job Template and the command gwsubmit. The GridWay Job Templates used during these executions are:
###############################################
# CREAM JOB: GridWay Job Template #
###############################################
EXECUTABLE = exp2exec.sh
ARGUMENTS = hello test4.jdl
INPUT_FILES = hello, test4.jdl
OUTPUT_FILES = exec.${JOB_ID}, txt.${JOB_ID}
STDOUT_FILE = stdout.${JOB_ID}
STDERR_FILE = stderr.${JOB_ID}
REQUIREMENTS = HOSTNAME = “cream-12.pd.infn.it”
###############################################
# LCG pre-WS JOB : GridWay Job Template #
###############################################
EXECUTABLE = exp2exec.sh
ARGUMENTS = hello test4.jdl
INPUT_FILES = hello, test4.jdl
OUTPUT_FILES = exec.${JOB_ID}, txt.${JOB_ID}
STDOUT_FILE = stdout.${JOB_ID}
STDERR_FILE = stderr.${JOB_ID}
REQUIREMENTS = HOSTNAME = “gridgate.cs.tcd.ie”
As we can see, the only difference between the two templates is the HOSTNAME field. In the two cases we specify the same executable with the same arguments, input and output files. However, we want GridWay executes each job in a different machine. Therefore, we only have to include the REQUIREMENTS attribute specifying the machine name where we want to execute the job. GridWay employs this attribute to execute the job using the suitable adapter in each case. In this way, we demonstrate that the interoperability with GridWay is transparent from de user point of view.
Finally, we can verify the status of two jobs using the command gwhistory.
