The DG to gLite bridge has two sides:
It has a BOINC side which is a modified BOINC Core Client that, instead of running the downloaded WUs locally, writes the contents of the WU to a jobwrapper config file and launches a jobwrapper process in place of the executable specified in the WU. The jobwrapper creates an archive of the slot directory and generates a shell script which extracts the archive, runs the executable specified in the WU and finally creates an output archive. Then it submits this script to a 3G Bridge queue on the same machine with the archived WU as its input. Then the jobwrapper stays running and tracks the execution via polling the 3G Bridge periodically and passing the results back to the BOINC client after the job has finished or if errors are encountered the jobwrapper exits with an error letting the BOINC client know about it.
The gLite side is a 3G Bridge instance with the EGEE output plugin that submits jobs to a gLite VO. The VO, WMS and the DN of the user used for job submission are specified in the plugin configuration. This is because in BOINC typically only the project administrator can install applications thus, the DN of the project administrator can be specified in the 3G Bridge plugin configuration. The proxies are retrieved from a MyProxy server by the 3G Bridge plugin. Also specified in the plugin configuration is a gsiftp accessible Storage Element which is used to transfer WU archives and output archives. This is done to avoid putting these files in the input and output sandbox that would generate too much load on the WMS.
The same 3G Bridge can have multiple instances of the EGEE plugin that are configured differently and handling different queues where jobs are submitted by different jobwrapper clients. Thus, a single BOINC ⇒ gLite bridge can connect several desktop grids and gLite VOs.
In order to realise this scenario, perform the following steps:
-
-
