EGI VO SLA guide

From EGIWiki
Revision as of 16:14, 5 January 2017 by Krakow (talk | contribs) (Required information to start)
Jump to: navigation, search
Main operations services Support Documentation Tools Activities Performance Technology Catch-all Services Resource Allocation Security

EGI OLA/SLA/UA framework: EGI OLA SLA framework EGI OLA SLA status Metric Definitions RC performance RP performance EGI services performance


The purpose of EGI VO SLA is to create a reliable, trust-based communication channel between the Customer and the Providers to agree on the services, their levels and the types of support.SLAs are not legal contracts but, as agreements, they outline the clear intentions to collaborate and support research activities.


For research communities

  • Better communication and clarity on expectations
  • Increased confidence that services will be delivered
  • Easier future planning of research activities

For resource providers

  • Direct communication with user communities and clarity on expectations    
  • Clear responsibilities and rules/policies concerning usage of the resources    
  • Recognition and greater visibility to role of the provider by requiring an explicit acknowledgment

For EGI Foundation

  • Promoting the EGI service value with funding agencies and policy makers at national and European level    
  • Being seen as mature partner    
  • Ensuring a foundation of a control process to what is being delivered in the EGI Federation


The EGI VO Agreements are covering delivery of IT services from EGI Catalogue


This section provides a high level description for VO SLA process. Through the whole process EGI Foundation is supporting the Customer and communicating the status.

After the end of the testing phase, EGI Foundation starts with the Customer the definition of an SLA. Information that are needed are described under SLA Required information

The SLA is a document describing the services and the amount of resources offered by EGI Foundation to the Customer for a given agreed time period.

EGI Foundation takes care of negotiating with the resource Providers on behalf of the Customer to define the SLA. Primarily, EGI Foundation contacts the EGI national representatives of the countries that are supporting the Customer to find Providers willing to support its activity. In addition, EGI Foundation is contacting Providers from other countries directly or through EGI Council.

At the end of this process, if successful, the Customer will have the guarantee that a certain amount of resources for a given period will be available. This should help the Customer to better plan future activity.

The SLA will be reviewed 12 months to check if it still fits the Customer requirements or it needs to be changed.

Before the SLA expires, EGI Foundation will contact the Customer to work on renewal if there is still a need.

The whole process is depicted in the following figure:

EGI VO SLA OLA process.png


Usually, for a scientific use cases, the EGI Foundation is looking for free resources leveraging on the interest of the Providers to support cutting-edge research according to their national roadmap.

Another option is pay for use model. In this case EGI Foundation will facilitate the process by putting together the Customer and the Providers which could satisfy the demand. The agreement and the contract will be signed between the Customer and the Providers.


EGI Foundation

  • EGI Foundation will manage the resource allocation process.
  • EGI Foundation will coordinate service delivery.
  • EGI Foundation will monitor the Service in order to measure the fulfilment of the agreed service level targets and report to the Customer.
  • EGI Foundation will manage of the Customer complains and disputes.


  • The Customer commits to acknowledge EGI Foundation and Providers in the scientific publications benefiting from the Service.
  • The Customer will provide reports agreed in the agreement. See section below.
  • The Customer must not cause any legal violation and the use must be consistent with the Acceptable Use Policy of the Service.


Following reports are required for the agreements:

Report title Contents When From To Frequency
Services Performance Report The document provides the overall assessment of service performance (per month) and SLA target performance achieved given period. Always EGI Foundation Customer Every six months
Platform Service report The document provides usage records (resources used, users) of the Customer service during given period The customer runs a service on top of EGI Resources Customer EGI Foundation Every six months
Scientific Publications report The document provides list of scientific publications benefiting from the Service. Always Customer EGI Foundation Yearly and with the Agreement ending

All reports shall follow predefined templates.

Required information to start

The Customer should provide following information to request the service:

General information

  • Customer contact: person (and email address) who will agree on SLA
  • Customer organization: legal entity which agree on SLA
  • Start date: preferred stat date of service to be delivered
  • End date: preferred end date of service to be delivered
  • Community description: up to 100-150 words
  • Country research community contact points: if any
  • EGI Participants currently supporting the community: if any
  • Current and future research impact: up to 500 words
  • EGI Virtual organization: name of virtual if exists
  • PaaS: is PaaS going to be provided to users based on the resources


  • Monthly availability: % (default: 90%)
  • Monthly reliability: % (default: 95%)
  • Cloud compute:
    • Number of Virtual CPU cores:
    • Memory:
    • Scratch/ephemeral storage:
    • Public IP addresses: if yes, required number
    • Payment mode offer: free or pay for use
    • Other technical requirements:
    • Duration:
    • Access type: Pledged/Opportunistic/Time allocation
  • High-Throughput Compute
    • Guaranteed computing time [HEPSPEC-hours]:
    • Opportunistic computing time [HEPSPEC-hours]:
    • Max job duration [hours]:
    • Min local storage [GB] (scratch space per each core used by the job):
    • Min physical memory per core [GB]:
    • Middleware:
    • Other technical requirements:
    • Duration:
    • Access type: Pledged/Opportunistic/Time allocation
  • Online Storage
    • Guaranteed storage capacity [TB]:
    • Opportunistic storage capacity [TB]:
    • Other technical requirements:
    • Duration:
    • Access type: Pledged/Opportunistic/Time allocation
  • Archive Storage
    • Guaranteed storage capacity [TB]:
    • Opportunistic storage capacity [TB]:
    • Other technical requirements:
    • Duration:
    • Access type: Pledged/Opportunistic/Time allocation

Possible access types:

  • Pledged - Resources are exclusively reserved to the Community and the job will be executed immediately after submission
  • Opportunistic - Resources are not exclusively allocated, but subject to local availability
  • Time allocation - Resources are available in fair share-like mode for a fixed time period.