Purpose

The purpose of an EGI VO Operational Level Agreement (OLA), or EGI VO Agreement for short, 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. The EGI VO Agreements are not legal contracts but, as agreements, they outline the clear intentions to collaborate and support research.

Benefits

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 acknowledgement

For research communities

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

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

Scope

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

Process

This section provides a high level description for the EGI VO Agreements' process. Through this process EGI Foundation is supporting the Customer's needs and communicating the status.

This process, which starts right after the end of the testing phase, can be described by the following steps:

  1. Firstly, EGI Foundation contacts the EGI national representatives of the countries that are supporting the Customer to find Providers willing to support its activity.
    • If necessary, other Providers, from other countries, will be contacted direclty or through EGI Council.
  2. EGI Foundation takes care of negotiating with the resource Providers on behalf of the Customer to define the SLA.
    • The SLA is a document describing the services and the amount of resources offered by EGI to the Customer for a given agreed time period.
    • Information needed for the creation of a SLA document can be found under the "SLA Required information" section.
  3. EGI Foundation opens a GGUS ticket and asks Operations Team to verify the configuration in the agreed providers.
  4. 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 plan future activity.
  5. Before the SLA expires, EGI Foundation will contact the Customer to work on renewal if there's still a need.


The whole process is depicted in the following figure:

Cost

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 Provider.

Responsibilities

As defined in Resource Center OLA. No additional responsibilities.

Reporting

As defined in Resource Center OLA.

Required information to start

The Provider should provide following information:

  • Provider contact: person (and email address) who will agree on OLA
  • Start date: stat date of service to be delivered
  • End date: end date of service to be delivered
  • Resources
    • Monthly Availability %: the ability of a service component to fulfill its intended function at a specific time or over a calendar month (default 90%).
    • Monthly Reliability %: the ability of a service component to fulfill its intended function at a specific time or over a calendar month, excluding maintenance periods (default 95%).
    • Cloud compute: (if any, please fill in the section)
      • Number of Virtual CPU cores:
      • Memory:
      • Scratch/ephemeral storage:
      • Public IP addresses: if yes, required number
      • Payment mode offer:
      • Other technical requirements:
      • Duration:
      • Access type:
    • High-Throughput Compute: (if any, please fill in the section)
      • 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:
    • Online Storage: (if any, please fill in the section)
      • Guaranteed storage capacity [TB]:
      • Opportunistic storage capacity [TB]:
      • Other technical requirements:
      • Duration:
      • Access type:

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.

  • No labels