| 6 | | BOINC is designed to rely on user decisions because they are the owners of the computer resources. However, there are situations where the users are not the owners of the PCs, for example the PCs of an institution like an University. In this case, the computers are controlled by the institution, so the institution decides in which tasks can be used those computers. In this new scenario BOINC lacks a tool to harness remotely all the BOINC enabled computers without the intervention of the user. For this reason, we are developing a tool called OGM. |
| | 7 | OGM is designed for situations where some entities that own computers ('''Suppliers''') |
| | 8 | have decided to let another entities (the '''Allocator''') |
| | 9 | decide how their computer time is to be divided among a set of BOINC projects. |
| | 10 | With OGM, Suppliers are able to control the usage of their computers |
| | 11 | (for example, the hours during which it does BOINC computation). |
| | 12 | However, they have no control over which BOINC projects their computers contribute to; |
| | 13 | the Allocator makes that decision. |
| 12 | | == OGM Components == |
| 13 | | OGM has two main components: the hardware and the administrators. Therefore, for OGM, from the point of view of hardware components, an institution has the following items: |
| 14 | | * '''Computer'''. This is the ''basic'' item of OGM. A computer here is named as a "BOINC working node". ''The institution must have at least one computer''. |
| 15 | | * '''Pool'''. A Pool is a set of ''zero or more computers'' that share something in common. For example, all the computers are located in the same laboratory. ''The institution must have at least one pool of computers''. |
| 16 | | * '''Department'''. A Department is a set of ''one or more Pools'' of computers that share something in common. For example, all the pools belongs to the math research group of the institution. ''An institution must have at least one Department''. |
| | 23 | For example, Suppliers might be different departments in a university, |
| | 24 | each of which owns a set of desktop and laboratory PCs, |
| | 25 | and the Allocator might be a campus-wide committee |
| | 26 | that divides the resources among BOINC projects internal to the university. |
| | 27 | Or the Suppliers might be different companies, |
| | 28 | who have agreed to volunteer their PC resources to a philanthropic |
| | 29 | organization that divides them among public BOINC projects. |
| 18 | | For OGM, from the point of view of managers, an institution has the following persons: |
| 19 | | * '''IT Manager'''. An IT Manager ''always belongs to one Department''. For this reason, the IT Manager can only administer the pools that belong to his department. |
| 20 | | * '''Project Manager'''. A Project Manager is in charge of choosing and attaching the BOINC projects that will run on the institution BOINC computers. |
| | 31 | OGM is implemented using BOINC's [AccountManagement Account Manager] mechanism. |
| | 32 | The Allocator runs the OGM software on a server. |
| | 33 | The Suppliers run the BOINC client on their computers, |
| | 34 | and attach each client to the Allocator's account manager. |
| | 35 | The BOINC client on the computer periodically communicates with the OGM, |
| | 36 | which instructs it which projects to attach to, |
| | 37 | and the resource share for each attachment. |
| 27 | | OGM employs roles to distinguish between the different OGM users: |
| 28 | | 1. '''The IT Manager role'''. This user can: |
| 29 | | * See the statistics of his pools of computers: CPU, RAM, HD, etc. |
| 30 | | * Change the BOINC preferences for the pools of his institution: |
| 31 | | * Time policy: Between which hours BOINC can use the PC resources. For example, the pool of computers A (which represents all the computers of laboratory 1) can work with BOINC from 9:00 am to 21:00 pm. |
| 32 | | * CPU use. The percentage of allowed CPU that BOINC can use. |
| 33 | | * RAM use. The percentage of allowed RAM that BOINC can use. |
| 34 | | * HD use. The percentage of allowed HD that BOINC can use. |
| 35 | | * ??? what else? |
| 36 | | 1. '''The Project Manager role'''. This user is in charge of: |
| 37 | | * Creating, Editing, Deleting BOINC projects. |
| 38 | | * Defining the Resource Share parameter for each BOINC project. |
| 39 | | 1. '''The root role'''. This user can do any task, is the ''super user'': |
| 40 | | * Admin (create, delete, edit) OGM users. |
| 41 | | * Do the tasks of an IT Manager. |
| 42 | | * Do the tasks of a Project Manager. |
| | 49 | OGM defines the following User roles: |
| | 50 | 1. '''Supplier Admin''': this user can: |
| | 51 | * See the statistics of computers in his Pools |
| | 52 | * Change the BOINC preferences for his pools (e.g., time of day limits, disk/RAM usage, etc.). |
| | 53 | 1. '''Allocator Admin''': this user can: |
| | 54 | * Create, edit, delete projects. |
| | 55 | * Set the Resource Share parameter for each Project. |
| | 56 | 1. '''Root''': this user can do any task: |
| | 57 | * Create, delete, edit OGM users. |
| | 58 | * Do the tasks of a Supplier Admin |
| | 59 | * Do the tasks of an Allocator Admin |
| 51 | | The default behavior for the Resource Sharing parameter is to divide equally the amount of time between all the attached projects. In a future, it will be interesting to implement an scheduler which attach projects to pools of computers based on: |
| 52 | | * Hardware specifications: |
| 53 | | * CPU |
| 54 | | * RAM |
| 55 | | * HD |
| 56 | | * Time table |
| 57 | | * ??? what else? |
| 58 | | * Time dead-lines. |
| 59 | | * Host churn. |
| 60 | | * ??? what else? |
| | 70 | In a future version of OGM, it would be possible to extend this model so that |
| | 71 | different resources shares are used on different Pools or Suppliers, for example |
| | 72 | so that Projects whose applications require particular hardware (e.g., large RAM) |
| | 73 | would be preferentially run on computers meeting those requirements. |
| 66 | | OGM assumes the following organizational structure: |
| 67 | | * There is a set of "resource pools" (groups of computers). Each resource pool is owned by an organizational unit (e.g. a research group, a university department, a division of a company, etc.). |
| 68 | | * There is a set of BOINC projects that are allowed to use these resources. These projects are operated by organizations (some of which may also manage resource pools). The projects may get resources from sources other than the OGM (e.g., from the public). |
| 69 | | * The set of organizations has agreed to cooperate in the sharing of computer resources. They all trust an organization (the OGM) to manage this sharing. |
| | 81 | The OGM has a single account on each Project, all with the same email address |
| | 82 | (i.e., there is not a separate account for each Supplier or Pool). |
| | 83 | This means that the OGM appears as a single user on each Project's "top users" list, |
| | 84 | and as a single user on aggregate statistics sites. |
| 71 | | Based on requests and constraints from resource providers and consumers, |
| 72 | | the OGM decides which projects to attach to which computers, |
| 73 | | and what resource share should be assigned. |
| 74 | | |
| 75 | | [[Image(ogm.png, nolink)]] |
| 76 | | |
| 77 | | |
| 78 | | |
| 79 | | OGM is implemented using BOINC's [AccountManagement Account Manager] mechanism. |
| 80 | | The computers in a particular resource pool are attached to a single OGM account. |
| 81 | | The BOINC client on the computer periodically communicates |
| 82 | | with the OGM, which instructs it which projects to attach to, |
| 83 | | and the resource share for each attachment. |
| 84 | | |
| 85 | | OGM provides different interfaces to different people. |
| 86 | | All the interfaces are web-based. |
| 87 | | |
| 88 | | For the OGM manager, the interfaces include: |
| 89 | | |
| 90 | | * Create and delete accounts for resource managers and project managers. |
| 91 | | * Decide what fraction of total resources is assigned to each project. |
| 92 | | * ??? what else? |
| 93 | | |
| 94 | | For resource managers, the interfaces include: |
| 95 | | |
| 96 | | * View list of computers in the pool. |
| 97 | | * Edit BOINC preferences for computers in the pool. |
| 98 | | * View set of projects currently using the pool. |
| 99 | | * ??? what else? |
| 100 | | |
| 101 | | For project managers, the interfaces include: |
| 102 | | |
| 103 | | * ??? what else? |
| | 86 | Thus, in order to allow Supplier Admins to view credit statistics for their Pools, |
| | 87 | the OGM must obtain per-host credit statistics from all the Projects using RPCs; |
| | 88 | it can then group these however it wants. |
