Difference between revisions of "Resource Allocation Process"
Jump to navigation
Jump to search
Line 42: | Line 42: | ||
*Pools definition may be subject of change according to specific policy | *Pools definition may be subject of change according to specific policy | ||
==Step 2== | == Step 2 == | ||
VO specifies and submits a resource request | |||
==Step 3== | ==Step 3== | ||
==Step 4== | ==Step 4== |
Revision as of 17:14, 8 March 2013
Main | EGI.eu operations services | Support | Documentation | Tools | Activities | Performance | Technology | Catch-all Services | Resource Allocation | Security |
<< Resource Allocation Task Force
Introduction
- Definition
- Let a pool be a specific capacity of resources available for EGI allocation according to defined process under defined conditions
Note: Pools covers all scenarios mentioned ever in RATF including “free hand”, “right to revoke”, “negotiation (elastic pool)”
The pool are defined in the Site/NGI declaration
- previously referred as pre-agreement, but it should not require EGI to agree/negotiate
- can be subject of change in time (some limitation apply)
Example
Pool-1-SiteA will offer:
- up to 100 cores in 2013 as reserved pool (as a whole), opportunistic inside pool
- “free hand” to EGI
- each VO should not be allocated more than 10% of the pool
Pool-2-SiteB will offer:
- up to 4000 cores between Jun’13 – Feb’14 with assigned fair-share
- allocation based on negotiations
- for requests that proved to be:
- at least good in EGI scientific review
- has members in NGI X
- each requests can be supported up to 50%
Process
Step 1
- NGI/Sites defines pools and register them in EGI
- Pools definition may be subject of change according to specific policy
Step 2
VO specifies and submits a resource request