Resource Allocation for Customer
|Main||EGI.eu operations services||Support||Documentation||Tools||Activities||Performance||Technology||Catch-all Services||Resource Allocation||Security|
|EGI Resource Allocation menu:|
The goal of the Resource Allocation (RA) process is to reach an agreement between Customer and Provider concerning the parameters and conditions of use of resources.The RA process is useful for the Customers (community representatives, Research Infrastructures, research projects, individual users) because in a multi-provider EGI environment they have a single point of contact to ask for a share on resources. RA is also beneficial for Providers (Site Manager, NGI Manager) as it allows more effectively plan the use of resources and closer communication with Customers.
The basic parameters of a RA contact are: duration and the amount of computing and /or storage resources. The EGI offer is expressed in a form of Resource Pools which are declared by Providers using common metrics. The Customers use the same metrics while describing their needs (resource request).
For basic terms used in Resource Allocation process, please go here
- Customer - scientist involved in a science project requesting storage or computing resources in EGI, person signing SLA with Resource Provider
- Broker - matchmaker and coordinator of RA process
- Resource Provider -Site Manager or NGI Manager responsible for resource allocation on sites in their scope
Log in through EGI SSO. If you have not an SSO account you can create one https://www.egi.eu/sso/email
After login to e-Grant you are directing to the dashboard. Here you can administrate yours SLAs, create new one, prepare drafts and control status of your requests.
- INBOX - contains SLAs awaiting for your action (negotiation, approval, rejection)
- OUTBOX - contains SLA documents being negotiated and awaiting for Broker's action (negotiation, approval, rejection)
- BINDING SLAs - documents with allocation being in place
- SLAs BINDING IN PART - documents with partial allocation being in place
- REJECTED REQUESTS/SLAs - rejected documents
- DRAFTS - drafts of SLAs, not available for provider
- STARRED - contains SLAs requiring special attention (documents starred by Customer)
A document created by Customer describing their resource requirements is a Resource Allocation Request (RA Request). In a reply to a Customer RA Request Broker creates an SLA containing one or more SLA Sections. There is one SLA Sections for each Resource Pool selected to satisfy a Request.
2. Here is the view for "Status info" with details of that new request.
3. Fill in information about:
- start date for using resources allocated within this SLA (at least 7 days ahead),
- end date for using the resources (no more than 1 year),
- user community or project for which resources will be used ,
- Virtual Organization that the Customer is affiliated with description of the activity (general information on what kind of computations will be performed)
selected metrics for requested resources. There are 4 types of resources available for EGI Customers: HTC Computing, HTC Storage, Cloud Computing and Cloud Storage. Detailed description for the metrics can be found here: metrics
To your disposition there is a context menu with helpful option during preparing the RA Request:
- You may save your request in draft state (is not being processed) and you can edit it later on.
- Before sending request you may invalidate it, by clicking on “Invalidate Request”.
- When satisfied with your Request, click “Send to EGI” button. The mail to Broker is sent. EGI RA team should contact you within 3 days.
After max. 3 days you should get response form Broker about requested resources. There can be a possibility that some of the information included in RA Request must be changed (Start Date, metric values etc.). It might be connected to Broker not being able to find requested resources from Pools available (then Broker will suggest changing some of the resource metrics) or Customer introducing wrong values by mistake (for example the End Date is set to one day later than the Start Date so Broker will suggest changing the End Date)
Changed request sent by Broker are in INBOX folder.
Changed metrics are highlighted (example below).
You have 3 option to choose:
- You can edit EGI proposal and still negotiate yours conditions.
- You can reject request (stop Resource Allocation process).
- You can accept changes proposed by Broker.
After editing request goes to OUTBOX
The next step is waiting for information about requested resources. If Broker finds resources suitable for a given RA Request then the SLA proposal will be send with underpinned SLA Sections containing resources offered by EGI Providers that can be allocated for Customer.
SLA proposals and SLA Section negotiations
SLA is a document created on the basis (in fact it is exact copy) of Customer Request. If Broker finds suitable resources for RA Request the SLA Proposal is sent to Customer. An SLA must contain at least one SLA Section. Each SLA Section is linked to an underpinning OLA (Document processed between EGI Provider and Broker) .
After receiving SLA proposal one of the following actions can be taken:
- Edit - Customer decides to change something in a given SLA proposal (for example, there is a need for more computing resources than when creating RA Request)
- Reject request - Customer wants to stop RA process. No resources allocated after this action
- Accept / Accept in Part - Customer accepts SLA proposal, resources included is SLA Sections underpinned to SLA proposal are allocated for Customer. When 'Accept in part' action is visible it means that resources included in underpinned SLA Section(s) are smaller than resources requested in RA Request (SLA proposal) but will available right away after accepting SLA in part. After accepting in part SLA proposal Broker is still looking for you the rest of requested resources.
When Customer is dissatisfied with resources offered for allocation (those resources are included in SLA Sections!), SLA section negotiation should be started.
SLA section created as an exact copy of a corresponding OLA, can be modified in the negotiation process. If changed, OLA will be modified accordingly be Broker. At the end of negotiations metrics values in SLA Section must be equal to those in OLA. SLA Section cannot be handled separately from SLA.
To negotiate resources given for allocation you have to open chosen SLA Section you want to modify by clicking on Version link in SLA Section list.
After opening SLA Section document choose Negotiate from context menu.
Change metrics and save proposal.
Info about saved changes will appear. Move to the SLA Document that given SLA Section is part of to send changed SLA proposal (with changed SLA Section) to EGI.
| SLA Section can be also rejected by Customer.
When rejecting SLA Section, Customer is resigning from any resources from Pool connected with rejected SLA Section. Broker must find resources from different RA Pools (RA Provider)
If agreement is reached, Customer signs SLA (action: Accept) and the offer is binding for both parties.
|SLA can become binding only if resources stated in SLA are equal to resources included in underpinned SLA Sections.|
Help and Support
To avoid problems with using e-Grant remember about using HINTS:
HELP! Button with help is on the left side. It shows hints oriented on the each options like on the example below:
Information marks. There is a lot of information marks next to the metrics inbox. When you point with mouse cursor on the mark the hint will show you like on example below:
Contact with us. The staff at EGI.eu will support the applicant at any point of the process, from request creation to accessing the assigned resources. Please send your questions to: email@example.com