| 1 | = CondorV: BOINC/Condor integration = |
| 2 | |
| 3 | This document describes the design of CondorV, extensions to BOINC and Condor |
| 4 | so that a BOINC-based volunteer computing project can provide resources to a Condor pool. |
| 5 | |
| 6 | Goals: |
| 7 | |
| 8 | * From the job submitter's viewpoint, |
| 9 | things should look as much like Condor as possible: |
| 10 | i.e. they prepare Condor submit files and use condor_submit. |
| 11 | |
| 12 | * Exception to the above: applications to be used in this way must be set up ahead of time |
| 13 | on the BOINC server. |
| 14 | |
| 15 | == Issues == |
| 16 | |
| 17 | CondorV must address some basic differences between Condor and BOINC: |
| 18 | |
| 19 | * Data model: in the BOINC model, files have both logical and physical names. |
| 20 | Physical names are unique within a project, |
| 21 | and the file associated with a given physical name is immutable. |
| 22 | Files may be used by many jobs. |
| 23 | In Condor, a file is associated with a job, and has a single name. |
| 24 | |
| 25 | * Application concept: |
| 26 | In Condor, a job is associated with a single executable, and can run |
| 27 | only on hosts of the appropriate platform (and possibly other attributes, |
| 28 | as specified by the job's ClassAd). |
| 29 | In BOINC, there may be many app versions for a single application: |
| 30 | e.g. versions for different platforms, GPU types, etc. |
| 31 | A job is associated with an application, not an app version. |
| 32 | |
| 33 | == Proposed architecture == |
| 34 | |
| 35 | We'll use Condor's existing mechanism for sending jobs to |
| 36 | non-Condor back ends. |
| 37 | This will involve 2 components: |
| 38 | |
| 39 | * A "BOINC GAHP" program. |
| 40 | * A new class in Condor's job_router for managing communication |
| 41 | with the BOINC GAHP. |
| 42 | |
| 43 | === Implementation notes === |
| 44 | |
| 45 | The BOINC GAHP will need to |