Resource Allocation Process
Main | EGI.eu operations services | Support | Documentation | Tools | Activities | Performance | Technology | Catch-all Services | Resource Allocation | Security |
<< Resource Allocation Task Force
This page is created by Resource Allocation Task Force. It contains proposal for RA process.
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)
Offer 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 Pools definition preparation
- NGI/Sites defines pools and register them in EGI
- Pools definition may be subject of change according to specific policy
Step 2 Request Submission
VO specifies and submits a resource request
Step 3 Pool matching
EGI Operator matches the resources request with currently available pools and decide on actions (may be more that one)
Step 4 Actions
Step 4a
In case some pools are matching the request, EGI operator can proceed with allocation according to process specified in the selected pool definition
Step 4b
In case the are missing resources EGI Operator can forward the request to scientific review.
After scientific review the request goes to step 3 again.
Step 4c
EGI Operator sends back the offer to the VO, in case:
- it covers the request,
- it covers the request partially, but there is no option to improve the situation
VO can accept the offer or reject it (or continue the negotiation with modified request – step 2 again)
Pool concept: specification
- Part 1: Pool Offer specification
- Description of what is offered (capacity)
- Validity in time
- Who is responsible (NGI / Site)
- Process definition (scenario)
- QoS (oportunistic | assigned share | reserved )
- Resource specification (metrics to define)
- Part 2: Acceptance criteria for requests
- Scope for VO (international | national, membership for NGI, discipline)
- Scientific review (not-required | at least (fair | good | excellent)
- Publications: required/not required
- Type of acknowledgments: EGI, NGI, Site
- Request size (also % of allocation)