CondorV: BOINC/Condor integration

This document describes the design of CondorV, extensions to BOINC and Condor so that a BOINC-based volunteer computing project can provide resources to a Condor pool.

Goals:

• From the job submitter's viewpoint, things should look as much like Condor as possible: i.e. they prepare Condor submit files and use condor_submit.

• Exception to the above: applications to be used in this way must be set up ahead of time on the BOINC server.

Issues

CondorV must address some basic differences between Condor and BOINC:

• Data model: in the BOINC model, files have both logical and physical names. Physical names are unique within a project, and the file associated with a given physical name is immutable. Files may be used by many jobs. In Condor, a file is associated with a job, and has a single name.

• Application concept: In Condor, a job is associated with a single executable, and can run only on hosts of the appropriate platform (and possibly other attributes, as specified by the job's ClassAd?). In BOINC, there may be many app versions for a single application: e.g. versions for different platforms, GPU types, etc. A job is associated with an application, not an app version.

Proposed architecture

We'll use Condor's existing mechanism for sending jobs to non-Condor back ends. This will involve 2 components:

• A "BOINC GAHP" program.
• A new class in Condor's job_router for managing communication with the BOINC GAHP.

Implementation notes

The BOINC GAHP will need to