Resource Allocation Procedure and Work Instruction

From EGIWiki
Revision as of 12:59, 7 April 2014 by Szymocha (talk | contribs) (Request tuning / fitting activities (matched or „around” matched))
Jump to: navigation, search

This is draft of procedure and related work instructions for User, Provider and Broker


Request – Service Level Agreement (SLA)

OLA – Operations Level Agreement – between and Resource Provieder

SLA Sections – Service Level Agreement Sections related to OLA with given Resource Provider

Customer - person signing SLA with Resource Provider

User - person using resources on base of binding SLA (could be Customer itself)


The effective usage of IT resources requires from Customers and Resource Provider reaching agreement on how much resources, with some specific requirements will be available to User at specific time period.

In heterogeneous IT environment it is difficult for Customers to find matching resources and for Resource Providers to manage their IT capacity.

The Resource Allocation process, if possible,  facilitates reaching agreement between Customers and Resource Providers.

Starting point are:

  • set of Resource Pools defined by Resource Providers describing in common metrics resources they are willing to deliver to Users
  • set of Customers expectations (Request) describing in common metrics resources they are willing to use

As a result of the process, if the Request was agreed by all parties, there is binding SLA signed, that is basis for resource configuration, allocation usage, support and allocation accounting.

In case there were not matched Requests, the output of the process is report to allowing to manage Pool Capacity (add new resources).

Creation of Resource Pool instruction (for Resource Providers)

Creation of Request instruction (for Customers)

Request Handling Procedure (draft)

User authentication

Broker checks that users has valid x.509 certificate supported by (e.g. EGI EUGridPMA organization). If not, Broker suggest User to obtain certificate.

Broker checks that User is member of VO. If not, Broker points User to documentation on creation of new vo:

Request validation (non blocking 3 days, executed in parallel)

Broker notifies ( Gergely Sipos). Veto to request(with explanations) should be e-mailed to resource-allocation-support at as soon as possible, no more than 3 days. This description will be sent to Customer.

Request vs resource pool matching (executed in parallel)

Broker matches resources. Broker choose pool according to scenario (Free hands, Right to revoke, Negotiated)

Request tuning activities

Broker checks wheter there was veto announced. If yes, Request is Rejected and Customer notified about reason.

If not, Broker sends to Customer SLA proposal.

1. User Request creation - C

2. User Request validation - C and B

3. OLA creation based on pool matching - B

4. OLA (re)negotiation - P and B

5. OLA confirmation/rejection  - P

6. SLA creation/updating  - B

7. SLA negotiation step - B and C

8. SLA confirmation/signing - C

Binding OLA configured on site (VO on site, resource allocation)

Resource Provider configures resources according to the binding Request.

Offer exploitation

User exploits the allocation. In case of problems creates ticket in GGUS assigned to "Resource Allocation" Support Unit. Then ticket may be assigned to related Resource Provider support unit.

Offer review

Customer evaluates the cooperation with

Work Instructions (draft)

1. User Side

Request creation

  1. Enter e-GRANT, login,
  2. Click “Request new allocation” button.
  3. Chose Start (at least 7 days ahead), end (no more than 1 year), user community, vo and enter description of activity field. Enter Computing time in HEPSPEC-hours, and Storage capacity (one of them may be zero). metrics
  4. You may safe your request in draft state (is not beeing processed) and you can edit it later on.
  5. Before sending request you may, by clicking on “Invalidate Request”.
  6. When satisfied with your Request, click “Submit to EGI” button. The mail to Broker is sent. EGI RA team should contact you within 3 days.

2. Provider Side

New OLA handling

  1. RP check (should be notified by email), that new OLA appeared (negotiation scenario)
  2. RP logs in to e-GRANT tool with GOCBD Admin role.
  3. In“Requests being processed” panel clicks on SLA Name to be processed.
  4. RPmay reject, negotiate and accept proposal.
  5. When RP wants to negotiate, clicks on “Negotiate” button.
  6. RP enters new proposed values. Then RP can save a draft or Send proposal. The mail to the Broker is sent.

3. Broker Side

New request handling

  1. Broker checks (should be notified by email), that new request appeared.
  2. Broker logs in to e-GRANT tool with Broker role.
  3. In “Requests being processed” panel clicks on SLA Name to be processed.
  4. Broker may reject, find pools or negotiate request.
  5. Broker clicks “Find pools”. There are possible pools shown.
  6. Broker checks metric values and decides on usage of given pool by clicking on the select box and click “Save” button.
  7. Broker clicks on related underpinned OLA, and clicks Send “OLA”. The mail to Resource Provider is sent.

Request negotiation (vs Provider)

  1. In “Requests being processed” panel clicks on SLA Name to be processed.
  2. In “Underpinned OLAs” clicks Version link
  3. Takes appropriate action.
  4. If Broker agrees, then click on “Accept” and “Home” to get to the list of all Requests.


mail: resource-allocation-support at

GGUS: "Resource Allocation" support unit (in preparation)